Minimal Invalidation of Dependent Objects
In the previous release, Oracle automatically invalidated all dependent views and PL/SQL packages during an online redefinition, even if those objects weren’t logically affected. For example, if you dropped a table column during redefinition, all procedures and views that referenced the table were automatically invalidated. Unlike in the previous releases, Oracle Database 11g invalidates only the logically affected objects such as views and synonyms during an online redefinition. It doesn’t automatically invalidate all dependent views and PL/SQL packages as before. In the case of a dropped column, Oracle will invalidate a procedure or view only if the object used the dropped column. This new concept of minimal validation of dependent objects is called fine-grained dependency management, under which the database tracks object dependencies at the level of the element within a unit.
Triggers continue to be automatically invalidated as before during an online redefinition.
Objects such as views, synonyms, and other similar table-dependent objects aren’t logically affected by a table redefinition and thus aren’t invalidated. Thus, for example, if an object referenced during an online redefinition isn’t modified during the redefinition, the object remains valid. All triggers that are defined on a redefined table will be invalidated, but the database automatically revalidates them when the next DML statement execution takes place.The use of fine-grained dependencies leads to more precise dependency metadata.
In Oracle Database 10g, the object dependency metadata was looked at from the object level. For example, let’s say a view depends on a specific table. Even though the addition of a new column to the table has no bearing on the view, the database still invalidates the view because it treats the entire object as the unit of reference. In Oracle Database 11g, the fact that a new column has been added to a table doesn’t invalidate a view that uses a table if the view doesn’t use the newly added column. Similar fine-grained dependency management applies to PL/SQL objects such as procedures and functions. If you add a new procedure or function to a package, that will invalidate other procedures and functions in that package only if those objects have a dependency on the altered or new procedure or function.
The fine-grained dependency management is easy to use, as it doesn’t need any configuration on your part. Your application availability will be higher as a result, especially during an application upgrade.
Sample
In previous releases, object dependencies were managed at the object level, so altering an object automatically invalidated all dependent objects. Oracle 11g has more granular dependency management, so only changes that directly affect an object will cause an invalidation. To show this create a table with a dependent package, which is in turn used by a view.
CREATE TABLE dep_tab (
id NUMBER,
description VARCHAR2(50),
CONSTRAINT dep_tab_pk PRIMARY KEY (id)
);
CREATE OR REPLACE PACKAGE dep_api AS
FUNCTION get_desc (p_id IN dep_tab.id%TYPE)
RETURN dep_tab.description%TYPE;
END dep_api;
/
CREATE OR REPLACE PACKAGE BODY dep_api AS
FUNCTION get_desc (p_id IN dep_tab.id%TYPE)
RETURN dep_tab.description%TYPE
AS
l_description dep_tab.description%TYPE;
BEGIN
SELECT description
INTO l_description
FROM dep_tab
WHERE id = p_id;
RETURN l_description;
END get_desc;
END dep_api;
/
CREATE OR REPLACE VIEW dept_tab_v AS
SELECT id, dep_api.get_desc(id) AS description
FROM dep_tab;
The objects in the schema are valid.
COLUMN object_name FORMAT A30
SELECT object_name, object_type, status FROM user_objects;
OBJECT_NAME OBJECT_TYPE STATUS
------------------------------ ------------------- -------
DEP_TAB TABLE VALID
DEP_TAB_PK INDEX VALID
DEP_API PACKAGE VALID
DEP_API PACKAGE BODY VALID
DEPT_TAB_V VIEW VALID
5 rows selected.
Add a column to the table and check the status of the schema objects. Prior to 11g we would expect both the package and the view to be invalidated by this operation.
ALTER TABLE dep_tab ADD (
record_type NUMBER(1)
);
SELECT object_name, object_type, status FROM user_objects;
OBJECT_NAME OBJECT_TYPE STATUS
------------------------------ ------------------- -------
DEP_TAB TABLE VALID
DEP_TAB_PK INDEX VALID
DEP_API PACKAGE VALID
DEP_API PACKAGE BODY INVALID
DEPT_TAB_V VIEW VALID
5 rows selected.
Notice the package specification and the view are not invalidated, because the table columns they reference are not changed by the addition of the new column. The package body is invalidated, but this is of little consequence since dependent objects reference the package specification, not the package body.
Next, recreate the package specification, adding the prototype for a new procedure, then check the status of the schema objects. We would expect this operation to invalidate the dependent view in releases prior to 11g.
CREATE OR REPLACE PACKAGE dep_api AS
FUNCTION get_desc (p_id IN dep_tab.id%TYPE)
RETURN dep_tab.description%TYPE;
PROCEDURE stub;
END dep_api;
/
SELECT object_name, object_type, status FROM user_objects;
OBJECT_NAME OBJECT_TYPE STATUS
------------------------------ ------------------- -------
DEP_TAB TABLE VALID
DEP_TAB_PK INDEX VALID
DEP_API PACKAGE VALID
DEP_API PACKAGE BODY INVALID
DEPT_TAB_V VIEW VALID
5 rows selected.
The dependent view is unaffected by the modification to the package specification.
参考至: 《McGraw.Hill.OCP.Oracle.Database.11g.New.Features.for.Administrators.Exam.Guide.Apr.2008》 http://www.oracle-base.com/articles/11g/enhanced-finer-grained-dependency-management-11gr1.php
本文原创，转载请注明出处、作者
如有错误，欢迎指正