Manage Oracle dependencies Notes

Oracle schema is the home for all the database objects. It shelters the entire set of objects which participate in the data storage layer (tables, views) and data access layer (package, procedures, functions, triggers). These objects can establish reference across themselves to embed one or the other application logic. This relationship between the two participating objects is known as Oracle Dependency; where one object acts as ‘Dependent object’, while the other one plays the role of ‘Referenced object’.

Dependent and Referenced Object

If an object A uses another object B within its definition, then the object A is known as Dependent object (on B). In the same case, the object B would be referred as Referenced object. Once the object A is compiled successfully, it establishes the relationship with the object B by virtue of its state. This implies that Oracle server identifies the state of an object as the relationship property between two related objects.

As stated, any object can behave as dependent or referenced object in particular situation, but this is not always true. Synonyms can always be categorized under referenced objects. Similarly, package body can always be a dependent object.

Direct and Indirect dependency

Conventional Dependency Management

Usually, if the referenced object undergoes a change, all its dependent objects are marked invalid. If the change is significant for the dependent object, it would be validated by the server in the very next call. This ‘DEPENDS ON’ matrix is maintained internally by Oracle. Oracle database implicitly toggles over the status of the objects and voluntarily takes decision to validate or invalidate them. The status of an object is determined by the value in the STATUS column of USER_OBJECTS dictionary view. It can be VALID for validated objects or INVALID for invalidated objects.

For instance, a procedure P_GET_SAL queries the EMPLOYEES table to get the salary of an employee. As per the dependency equation, P_GET_SAL is dependent on EMPLOYEES (referenced) table. If EMPLOYEES table is altered to add a new column “commission”, procedure P_GET_SAL is immediately invalidated. Hereafter, whenever P_GET_SAL would be invoked, it would throw exception of ‘Snapshot too old’. But in the very next call, Oracle server compiles the invalidated objects.

Apart from the above scenario, object dependency might bump the database business layer activities for a while. In addition, if the database makes use of synonyms and view, it always runs the threat of being affected by object dependencies.

Oracle 10g even made certain modifications in synonyms to succumb over the dependency issue. Oracle 11g implemented an algorithm, known as Fine Grained Dependency, to handle the dependency from the depth. The new concept has changed the granularity of dependency from object to element. Let us now go through the concept in detail.

{mospagebreak}

Recapitulate Object status in a schema

Now, let us take a look at the possible status(s) of an object in a schema. The object status gets updated in the STATUS column of [ALL | DBA | USER]_OBJECTS dictionary view for all objects within the database/schema. The column can also be found in [ALL | DBA | USER]_PROCEDURES which holds subprogram and package information only. I will list the probable status(s) of an existing object.

Status	Description
VALID	The object exists in compiled state. All referenced objects too are stable
COMPILED WITH ERRORS	The objects failed to compile due to some syntactical errors.
INVALID	The object exists with its referenced objects altered and modified
UNAUTHORIZED	If any privilege has been revoked from the referenced object, dependent object is marked UNAUTHORIZED

USER_DEPENDENCIES view

The dependency matrix of an object is maintained by [ALL | DBA | USER]_DEPENDENCIES dictionary view in Oracle. It captures the referenced object’s name, type, owner, and db link information.

Track Direct and Indirect dependency views

Besides USER_DEPENDENCIES dictionary view, Oracle provides two additional views to track direct and indirect dependency of the object. These views are DEPTREE (direct dependencies) and IDEPTREE (indirect dependencies), which do not exist in the schema as other dictionary view, but their script can be found in ORACLE_HOME.

Steps to follow

1. Execute the UTLDTREE.sql script from ORACLE_HOME/rdbms/admin folder.
2. Execute the DEPTREE_FILL procedure to populate the DEPTREE_TEMPTAB table.

How to use?

Suppose, I want to check the dependency level of a procedure P_GET_SAL, I would execute the DEPTREE_FILL procedure in the below fashion.

EXEC DEPTREE_FILL(‘PROCEDURE’,’SCOTT’,’P_GET_SAL’);

Above statement would populate the dependency matrix into DEPTREE_TEMPTAB table. The view DEPTREE AND IDEPTREE are created on top of DEPTREE_TEMPTAB.

{mospagebreak}

Fine grained dependency

Fine grained dependency is one of the key enhancements of Oracle 11g. The new concept has taken the object dependency concept to an instrumental level so as to assure minimum hindrance in database object validations.

Introduction to Dependency Issues

Some types of schema objects can reference other objects as part of their definition. For example, a view is defined by a query that references tables or other views. A procedure's body can include SQL statements that reference other objects of a database. An object that references another object as part of its definition is called a dependent object, while the object being referenced is a referenced object.Figure 6-1 illustrates the different types of dependent and referenced objects:

Figure 6-1 Types of Possible Dependent and Referenced Schema Objects

Description of "Figure 6-1 Types of Possible Dependent and Referenced Schema Objects"

If you alter the definition of a referenced object, dependent objects may or may not continue to function without error, depending on the type of alteration. For example, if you drop a table, no view based on the dropped table is usable.

Oracle automatically records dependencies among objects to alleviate the complex job of dependency management for the database administrator and users. For example, if you alter a table on which several stored procedures depend, Oracle automatically recompiles the dependent procedures the next time the procedures are referenced (run or compiled against).

To manage dependencies among schema objects, all of the schema objects in a database have a status.

• Valid schema objects have been compiled and can be immediately used when referenced.
• Invalid schema objects must be compiled before they can be used.
  • For procedures, functions, and packages, this means compiling the schema object.
  • For views, this means that the view must be reparsed, using the current definition in the data dictionary.
  Only dependent objects can be invalid. Tables, sequences, and synonyms are always valid.
  If a view, procedure, function, or package is invalid, Oracle may have attempted to compile it, but errors relating to the object occurred. For example, when compiling a view, one of its base tables might not exist, or the correct privileges for the base table might not be present. When compiling a package, there might be a PL/SQL or SQL syntax error, or the correct privileges for a referenced object might not be present. Schema objects with such problems remain invalid.

Oracle automatically tracks specific changes in the database and records the appropriate status for related objects in the data dictionary.

Status recording is a recursive process. Any change in the status of a referenced object changes the status not only for directly dependent objects, but also for indirectly dependent objects.

For example, consider a stored procedure that directly references a view. In effect, the stored procedure indirectly references the base tables of that view. Therefore, if you alter a base table, the view is invalidated, which then invalidates the stored procedure. Figure 6-2illustrates indirect dependencies:

Figure 6-2 Indirect Dependencies

Description of "Figure 6-2 Indirect Dependencies"

Resolution of Schema Object Dependencies

When a schema object is referenced directly in a SQL statement or indirectly through a reference to a dependent object, Oracle checks the status of the object explicitly specified in the SQL statement and any referenced objects, as necessary. Oracle's action depends on the status of the objects that are directly and indirectly referenced in a SQL statement:

• If every referenced object is valid, then Oracle runs the SQL statement immediately without any additional work.
• If any referenced view or PL/SQL program unit (procedure, function, or package) is invalid, then Oracle automatically attempts to compile the object.
  • If all invalid referenced objects can be compiled successfully, then they are compiled and Oracle runs the SQL statement.
  • If an invalid object cannot be compiled successfully, then it remains invalid. Oracle returns an error and rolls back the failing SQL statement. The rest of the transaction is unaltered and can be committed or rolled back by the user.
    Note:

    Oracle attempts to recompile an invalid object dynamically only if it has not been replaced since it was detected as invalid. This optimization eliminates unnecessary recompilations.

Compilation of Views and PL/SQL Program Units

A view or PL/SQL program unit can be compiled and made valid if the following conditions are satisfied:

• The definition of the view or program unit must be correct. All of the SQL and PL/SQL statements must be proper constructs.
• All referenced objects must be present and of the expected structure. For example, if the defining query of a view includes a column, the column must be present in the base table.
• The owner of the view or program unit must have the necessary privileges for the referenced objects. For example, if a SQL statement in a procedure inserts a row into a table, the owner of the procedure must have the INSERT privilege for the referenced table.

Views and Base Tables

A view depends on the base tables or views referenced in its defining query. If the defining query of a view is not explicit about which columns are referenced, for example, SELECT * FROM table, then the defining query is expanded when stored in the data dictionary to include all columns in the referenced base table at that time.

If a base table or view of a view is altered, renamed, or dropped, then the view is invalidated, but its definition remains in the data dictionary along with the privileges, synonyms, other objects, and other views that reference the invalid view.

Note:

Whenever you create a table, index, and view, and then drop the table, all objects dependent on that table are invalidated, including views, packages, package bodies, functions, and procedures.

An attempt to use an invalid view automatically causes Oracle to recompile the view dynamically. After replacing the view, the view might be valid or invalid, depending on the following conditions:

• All base tables referenced by the defining query of a view must exist. If a base table of a view is renamed or dropped, the view is invalidated and cannot be used. References to invalid views cause the referencing statement to fail. The view can be compiled only if the base table is renamed to its original name or the base table is re-created.
• If a base table is altered or re-created with the same columns, but the datatype of one or more columns in the base table is changed, then most dependent views can be recompiled successfully.
• If a base table of a view is altered or re-created with at least the same set of columns, then the view can be validated. The view cannot be validated if the base table is re-created with new columns and the view references columns no longer contained in the re-created table. The latter point is especially relevant in the case of views defined with a SELECT * FROM table query, because the defining query is expanded at view creation time and permanently stored in the data dictionary.

Program Units and Referenced Objects

Oracle automatically invalidates a program unit when the definition of a referenced object is altered. For example, assume that a standalone procedure includes several statements that reference a table, a view, another standalone procedure, and a public package procedure. In that case, the following conditions hold:

• If the referenced table is altered, then the dependent procedure is invalidated.
• If the base table of the referenced view is altered, then the view and the dependent procedure are invalidated.
• If the referenced standalone procedure is replaced, then the dependent procedure is invalidated.
• If the body of the referenced package is replaced, then the dependent procedure is not affected. However, if the specification of the referenced package is replaced, then the dependent procedure is invalidated. This is a mechanism for minimizing dependencies among procedures and referenced objects by using packages.
• Whenever you create a table, index, and view, and then drop the table, all objects dependent on that table are invalidated, including views, packages, package bodies, functions, and procedures.

Data Warehousing Considerations

Some data warehouses drop indexes on tables at night to facilitate faster loads. However, all views dependent on the table whose index is dropped get invalidated. This means that subsequently running any package that reference these dropped views will invalidate the package.

Remember that whenever you create a table, index, and view, and then drop the index, all objects dependent on that table are invalidated, including views, packages, package bodies, functions, and procedures. This protects updatable join views.

To make the view valid again, use one of the following statements:

SELECT * FROM vtest;

or

ALTER VIEW vtest compile;

Session State and Referenced Packages

Each session that references a package construct has its own instance of that package, including a persistent state of any public and private variables, cursors, and constants. All of a session's package instantiations including state can be lost if any of the session's instantiated packages are subsequently invalidated and recompiled.

Security Authorizations

Oracle notices when a DML object or system privilege is granted to or revoked from a user or PUBLIC and automatically invalidates all the owner's dependent objects. Oracle invalidates the dependent objects to verify that an owner of a dependent object continues to have the necessary privileges for all referenced objects. Internally, Oracle notes that such objects do not have to be recompiled. Only security authorizations need to be validated, not the structure of any objects. This optimization eliminates unnecessary recompilations and prevents the need to change a dependent object's time stamp.

See Also:

Oracle Database Application Developer's Guide - Fundamentals for information about forcing the recompilation of an invalid view or program unit

Object Name Resolution

Object names referenced in SQL statements can consist of several pieces, separated by periods. The following describes how Oracle resolves an object name.

1. Oracle attempts to qualify the first piece of the name referenced in the SQL statement. For example, in hr.employees, hr is the first piece. If there is only one piece, then the one piece is considered the first piece.
   1. In the current schema, Oracle searches for an object whose name matches the first piece of the object name. If it does not find such an object, then it continues with step b.
   2. Oracle searches for a public synonym that matches the first piece of the name. If it does not find one, then it continues with step c.
   3. Oracle searches for a schema whose name matches the first piece of the object name. If it finds one, then it returns to step b, now using the second piece of the name as the object to find in the qualified schema. If the second piece does not correspond to an object in the previously qualified schema or there is not a second piece, then Oracle returns an error.
   If no schema is found in step c, then the object cannot be qualified and Oracle returns an error.
2. A schema object has been qualified. Any remaining pieces of the name must match a valid part of the found object. For example, if hr.employees.department_id is the name, then hr is qualified as a schema, employees is qualified as a table, anddepartment_id must correspond to a column (because employees is a table). If employees is qualified as a package, thendepartment_id must correspond to a public constant, variable, procedure, or function of that package.

Because of how Oracle resolves references, it is possible for an object to depend on the nonexistence of other objects. This situation occurs when the dependent object uses a reference that would be interpreted differently were another object present.

See Also:

Oracle Database Administrator's Guide

Shared SQL Dependency Management

In addition to managing dependencies among schema objects, Oracle also manages dependencies of each shared SQL area in the shared pool. If a table, view, synonym, or sequence is created, altered, or dropped, or a procedure or package specification is recompiled, all dependent shared SQL areas are invalidated. At a subsequent execution of the cursor that corresponds to an invalidated shared SQL area, Oracle reparses the SQL statement to regenerate the shared SQL area.

Local and Remote Dependency Management

Tracking dependencies and completing necessary recompilations are performed automatically by Oracle. Local dependency managementoccurs when Oracle manages dependencies among the objects in a single database. For example, a statement in a procedure can reference a table in the same database.

Remote dependency management occurs when Oracle manages dependencies in distributed environments across a network. For example, an Oracle Forms trigger can depend on a schema object in the database. In a distributed database, a local view's defining query can reference a remote table.

Management of Local Dependencies

Oracle manages all local dependencies using the database's internal dependency table, which keeps track of each schema object's dependent objects. When a referenced object is modified, Oracle uses the depends-on table to identify dependent objects, which are then invalidated.

For example, assume a stored procedure UPDATE_SAL references the table JWARD.employees. If the definition of the table is altered in any way, the status of every object that references JWARD.employees is changed to INVALID, including the stored procedure UPDATE_SAL. As a result, the procedure cannot be run until it has been recompiled and is valid. Similarly, when a DML privilege is revoked from a user, every dependent object in the user's schema is invalidated. However, an object that is invalid because authorization was revoked can be revalidated by "reauthorization," in which case it does not require full recompilation.

Management of Remote Dependencies

Oracle also manages application-to-database and distributed database dependencies. For example, an Oracle Forms application might contain a trigger that references a table, or a local stored procedure might call a remote procedure in a distributed database system. The database system must account for dependencies among such objects. Oracle uses different mechanisms to manage remote dependencies, depending on the objects involved.

Dependencies Among Local and Remote Database Procedures

Dependencies among stored procedures including functions, packages, and triggers in a distributed database system are managed usingtime stamp checking or signature checking.

The dynamic initialization parameter REMOTE_DEPENDENCIES_MODE determines whether time stamps or signatures govern remote dependencies.

See Also:

Oracle Database Application Developer's Guide - Fundamentals for details about managing remote dependencies with time stamps or signatures

Time stamp Checking

In the time stamp checking dependency model, whenever a procedure is compiled or recompiled its time stamp (the time it is created, altered, or replaced) is recorded in the data dictionary. The time stamp is a record of the time the procedure is created, altered, or replaced. Additionally, the compiled version of the procedure contains information about each remote procedure that it references, including the remote procedure's schema, package name, procedure name, and time stamp.

When a dependent procedure is used, Oracle compares the remote time stamps recorded at compile time with the current time stamps of the remotely referenced procedures. Depending on the result of this comparison, two situations can occur:

• The local and remote procedures run without compilation if the time stamps match.
• The local procedure is invalidated if any time stamps of remotely referenced procedures do not match, and an error is returned to the calling environment. Furthermore, all other local procedures that depend on the remote procedure with the new time stamp are also invalidated. For example, assume several local procedures call a remote procedure, and the remote procedure is recompiled. When one of the local procedures is run and notices the different time stamp of the remote procedure, every local procedure that depends on the remote procedure is invalidated.

Actual time stamp comparison occurs when a statement in the body of a local procedure runs a remote procedure. Only at this moment are the time stamps compared using the distributed database's communications link. Therefore, all statements in a local procedure that precede an invalid procedure call might run successfully. Statements subsequent to an invalid procedure call do not run at all. Compilation is required.

Depending on how the invalid procedure is called, DML statements run before the invalid procedure call are rolled back. For example, in the following, the UPDATE results are rolled back as the complete PL/SQL block changes are rolled back.

BEGIN

UPDATE table set ...
invalid_proc;
COMMIT;

END;

However, with the following, the UPDATE results are final. Only the PROC call is rolled back.

UPDATE table set ...
EXECUTE invalid_proc;
COMMIT;

Signature Checking

Oracle provides the additional capability of remote dependencies using signatures. The signature capability affects only remote dependencies. Local dependencies are not affected, as recompilation is always possible in this environment.

The signature of a procedure contains information about the following items:

• Name of the package, procedure, or function
• Base types of the parameters
• Modes of the parameters (IN, OUT, and IN OUT)
  Note:

  Only the types and modes of parameters are significant. The name of the parameter does not affect the signature.

If the signature dependency model is in effect, a dependency on a remote program unit causes an invalidation of the dependent unit if the dependent unit contains a call to a procedure in the parent unit, and the signature of this procedure has been changed in an incompatible manner. A program unit can be a package, stored procedure, stored function, or trigger.

Dependencies Among Other Remote Schema Objects

Oracle does not manage dependencies among remote schema objects other than local-procedure-to-remote-procedure dependencies.

For example, assume that a local view is created and defined by a query that references a remote table. Also assume that a local procedure includes a SQL statement that references the same remote table. Later, the definition of the table is altered.

As a result, the local view and procedure are never invalidated, even if the view or procedure is used after the table is altered, and even if the view or procedure now returns errors when used. In this case, the view or procedure must be altered manually so that errors are not returned. In such cases, lack of dependency management is preferable to unnecessary recompilations of dependent objects.

Dependencies of Applications

Code in database applications can reference objects in the connected database. For example, OCI and precompiler applications can submit anonymous PL/SQL blocks. Triggers in Oracle Forms applications can reference a schema object.

Such applications are dependent on the schema objects they reference. Dependency management techniques vary, depending on the development environment.

Summary: Object dependency is the term used in Oracle to express how an object depends on another. When objects are dependent of each other they are linked and if either one has a problem the developer may have to fix the error to make the object valid again. This video explain the scenarios and situations where object dependency is an issue in Oracle and provide some examples that show how an object can be invalid because of a broken chain on dependency. The video also discuss some aspects and recommendations to avoid problems when objects are linked and depend of each other.