19.1.1 Data Dictionary Views for pl/sql Programmers

The Oracle data dictionary is a jungle! There are hundreds of views built on hundreds of tables, many complex interrelationships, special codes, and, all too often, non-optimized view definitions. In general, there are three types or levels of data dictionary views:

USER_*

Views that show information about the database objects owned by the currently connected schema.

ALL_*

Views that show information about all of the database objects to which the currently connected schema has access (either because it owns them or because it has been granted access to them).

DBA_*

Views that show information about all the objects in the database.

Because the stored objects are contained in tables in the data dictionary, you can use SQL itself to get information about the currently available programs. The following views are the most useful to understand:

USER_DEPENDENCIES

The dependencies to and from objects you own.

USER_ERRORS

The current set of errors for all stored objects you own. This view is accessed by the SHOW ERRORS SQL*Plus command, described in Chapter 2.

USER_OBJECTS

The objects you own.

USER_OBJECT_SIZE

The size of the objects you own.

USER_SOURCE

The text source code for all objects you own.

USER_TRIGGERS

The database triggers you own.

USER_ARGUMENTS

The arguments (parameters) in all the procedures and functions in your schema.

You can view the structures of each of these views either with aDESC (describe) command in SQL*Plus or by referring to the appropriate Oracle documentation. The following sections provide some examples of the ways you can use these views.

19.1.2 Displaying Information About Stored Objects

The USER_OBJECTS view contains the following key information about an object:

OBJECT_NAME

Name of the object

OBJECT_TYPE

Type of the object

STATUS

Status of the object: VALID or INVALID

Here are some of the types of objects (those most pertinent to PL/SQL developers) that are accessible through this view:

SQL> SELECT distinct object_type FROM user_objects;

OBJECT_TYPE

-------------

FUNCTION

INDEX

JAVA CLASS

JAVA SOURCE

LOB

PACKAGE

PACKAGE BODY

PROCEDURE

SEQUENCE

SYNONYM

TABLE

TRIGGER

TYPE

TYPE BODY

VIEW

You can see that USER_OBJECTS does more than keep track of PL/SQL code; you can use it to obtain a list of allPL/SQL objects currently in the database. I created and ran the following SQL*Plus script in a file called psobj.sql, which you'll find on the O'Reilly site:

/* File on web: psobj.sql */

SET PAGESIZE 66

COLUMN object_type FORMAT A20

COLUMN object_name FORMAT A30

COLUMN status FORMAT A10

BREAK ON object_type SKIP 1

SPOOL psobj.lis

SELECT object_type, object_name, status

FROM user_objects

WHERE object_type IN (

'PACKAGE', 'PACKAGE BODY', 'FUNCTION', 'PROCEDURE',

'TYPE', 'TYPE BODY')

ORDER BY object_type, status, object_name

/

SPOOL OFF

The output from this script file contained the following list:

OBJECT_TYPE OBJECT_NAME STATUS

-------------------- ------------------------------ ----------

FUNCTION DEVELOP_ANALYSIS INVALID

NUMBER_OF_ATOMICS INVALID

FREQ_INSTR VALID

PACKAGE CONFIG_PKG VALID

EXCHDLR_PKG VALID

PACKAGE BODY EXCHDLR_PKG VALID

PROCEDURE ASSESS_POPULARITY INVALID

ASSERT_CONDITION VALID

TYPE DESSERT_T VALID

TYPE BODY DESSERT_T VALID

Notice that a number of my modules are marked as INVALID. This may be due to changes to the tables referenced in the modules, or changes to other programs called by these modules. The RDBMS automatically recompiles these objects when a program tries to call them. In other words, this recompilation takes place at runtime, when the user has caused these programs to be run and is waiting while the compilation occurs. You can avoid this automatic recompilation (and its impact on users) by manually compiling the INVALID modules yourself. The best way to do this is to use the excellent recompile utility, built by Solomon Yakobson and found in recompile.sql on the O'Reilly site.