05.11.2015 Views

Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

CHAPTER 6 ■ LOCKING AND LATCHING 219<br />

The last type of DDL lock is a breakable parse lock. When your session parses a statement,<br />

a parse lock is taken against every object referenced by that statement. These locks are taken<br />

in order to allow the parsed, cached statement to be invalidated (flushed) in the Shared pool if<br />

a referenced object is dropped or altered in some way.<br />

A view that is invaluable for looking at this information is DBA_DDL_LOCKS. There is no V$<br />

view for you to look at. The DBA_DDL_LOCKS view is built on the more mysterious X$ tables <strong>and</strong>,<br />

by default, it will not be installed in your database. You can install this <strong>and</strong> other locking views<br />

by running the catblock.sql script found in the directory [ORACLE_HOME]/rdbms/admin. This<br />

script must be executed as the user SYS in order to succeed. Once you have executed this<br />

script, you can run a query against the view. For example, in a single-user database I see the<br />

following:<br />

ops$tkyte@ORA10G> select session_id sid, owner, name, type,<br />

2 mode_held held, mode_requested request<br />

3 from dba_ddl_locks;<br />

SID OWNER NAME TYPE HELD REQUEST<br />

---- --------- --------------------- -------------------- ---- ---------<br />

161 SYS DBMS_UTILITY Body Null None<br />

161 SYS DBMS_UTILITY Body Null None<br />

161 SYS DBMS_APPLICATION_INFO Table/Procedure/Type Null None<br />

161 OPS$TKYTE OPS$TKYTE 18 Null None<br />

161 SYS DBMS_OUTPUT Body Null None<br />

161 SYS DATABASE 18 Null None<br />

161 SYS DBMS_UTILITY Table/Procedure/Type Null None<br />

161 SYS DBMS_UTILITY Table/Procedure/Type Null None<br />

161 SYS PLITBLM Table/Procedure/Type Null None<br />

161 SYS DBMS_APPLICATION_INFO Body Null None<br />

161 SYS DBMS_OUTPUT Table/Procedure/Type Null None<br />

11 rows selected.<br />

These are all the objects that my session is “locking.” I have breakable parse locks on a<br />

couple of the DBMS_* packages. These are a side effect of using SQL*Plus; it calls DBMS_<br />

APPLICATION_INFO, for example. I may see more than one copy of various objects here—this is<br />

normal, <strong>and</strong> it just means I have more than one thing I’m using in the Shared pool that references<br />

these objects. It is interesting to note that in the view, the OWNER column is not the owner<br />

of the lock; rather, it is the owner of the object being locked. This is why you see many SYS<br />

rows. SYS owns these packages, but they all belong to my session.<br />

To see a breakable parse lock in action, let’s first create <strong>and</strong> run a stored procedure, P:<br />

ops$tkyte@ORA10G> create or replace procedure p as begin null; end;<br />

2 /<br />

Procedure created.<br />

ops$tkyte@ORA10G> exec p<br />

PL/SQL procedure successfully completed.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!