05.11.2015 Views

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

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

CHAPTER 6 ■ LOCKING AND LATCHING 217<br />

USERNAME SID ID1 ID2 LMODE REQUEST BLOCK TYPE<br />

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

OPS$TKYTE 161 262151 16584 6 0 0 TX<br />

OPS$TKYTE 161 62074 0 3 0 0 TM<br />

OPS$TKYTE 161 62073 0 3 0 0 TM<br />

ops$tkyte@ORA10G> select object_name, object_id<br />

2 from user_objects<br />

3 where object_name in ('T1','T2')<br />

4 /<br />

OBJECT_NAME OBJECT_ID<br />

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

T1 62073<br />

T2 62074<br />

Whereas we get only one TX lock per transaction, we can get as many TM locks as the<br />

objects we modify. Here, the interesting thing is that the ID1 column for the TM lock is the object<br />

ID of the DML-locked object, so it easy to find the object on which the lock is being held.<br />

An interesting aside to the TM lock: the total number of TM locks allowed in the system is<br />

configurable by you (for details, see the DML_LOCKS parameter definition in the <strong>Oracle</strong> <strong>Database</strong><br />

Reference manual). It may in fact be set to zero. This does not mean that your database<br />

becomes a read-only database (no locks), but rather that DDL is not permitted. This is useful<br />

in very specialized applications, such as RAC implementations, to reduce the amount of intrainstance<br />

coordination that would otherwise take place. You can also remove the ability to gain<br />

TM locks on an object-by-object basis using the ALTER TABLE TABLENAME DISABLE TABLE LOCK<br />

comm<strong>and</strong>. This is a quick way to make it “harder” to accidentally drop a table, as you will have<br />

to re-enable the table lock before dropping the table. It can also be used to detect a full table<br />

lock as a result of the unindexed foreign key we discussed previously.<br />

DDL Locks<br />

DDL locks are automatically placed against objects during a DDL operation to protect them<br />

from changes by other sessions. For example, if I perform the DDL operation ALTERTABLE T, the<br />

table T will have an exclusive DDL lock placed against it, preventing other sessions from getting<br />

DDL locks <strong>and</strong> TM locks on this table. DDL locks are held for the duration of the DDL<br />

statement <strong>and</strong> are released immediately afterward. This is done, in effect, by always wrapping<br />

DDL statements in implicit commits (or a commit/rollback pair). For this reason, DDL always<br />

commits in <strong>Oracle</strong>. Every CREATE, ALTER, <strong>and</strong> so on statement is really executed as shown in<br />

this pseudo-code:<br />

Begin<br />

Commit;<br />

DDL-STATEMENT<br />

Commit;<br />

Exception<br />

When others then rollback;<br />

End;

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

Saved successfully!

Ooh no, something went wrong!