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.

204<br />

CHAPTER 6 ■ LOCKING AND LATCHING<br />

become available. After receiving the deadlock message, session B must decide whether to<br />

commit the outst<strong>and</strong>ing work on table B, roll it back, or continue down an alternate path<br />

<strong>and</strong> commit later. As soon as this session does commit or roll back, the other blocked session<br />

will continue on as if nothing happened.<br />

<strong>Oracle</strong> considers deadlocks to be so rare, so unusual, that it creates a trace file on the<br />

server each <strong>and</strong> every time one does occur. The contents of the trace file will look something<br />

like this:<br />

*** 2005-04-25 15:53:01.455<br />

*** ACTION NAME:() 2005-04-25 15:53:01.455<br />

*** MODULE NAME:(SQL*Plus) 2005-04-25 15:53:01.455<br />

*** SERVICE NAME:(SYS$USERS) 2005-04-25 15:53:01.455<br />

*** SESSION ID:(145.208) 2005-04-25 15:53:01.455<br />

DEADLOCK DETECTED<br />

Current SQL statement for this session:<br />

update a set x = 1<br />

The following deadlock is not an ORACLE error. It is a<br />

deadlock due to user error in the design of an application<br />

or from issuing incorrect ad-hoc SQL. The following<br />

information may aid in determining the deadlock:...<br />

Obviously, <strong>Oracle</strong> considers these application deadlocks a self-induced error on part of<br />

the application <strong>and</strong>, for the most part, <strong>Oracle</strong> is correct. Unlike in many other RDBMSs, deadlocks<br />

are so rare in <strong>Oracle</strong> they can be considered almost nonexistent. Typically, you must<br />

come up with artificial conditions to get one.<br />

The number one cause of deadlocks in the <strong>Oracle</strong> database, in my experience, is unindexed<br />

foreign keys (the number two cause is bitmap indexes on tables subject to concurrent<br />

updates, which we’ll cover in Chapter 11). <strong>Oracle</strong> will place a full table lock on a child table<br />

after modification of the parent table in two cases:<br />

• If you update the parent table’s primary key (a very rare occurrence if you follow the<br />

rule of relational databases stating that primary keys should be immutable), the child<br />

table will be locked in the absence of an index on the foreign key.<br />

• If you delete a parent table row, the entire child table will be locked (in the absence of<br />

an index on the foreign key) as well.<br />

These full table locks are a short-term occurrence in <strong>Oracle</strong>9i <strong>and</strong> above, meaning they<br />

need to be taken for the duration of the DML operation, not the entire transaction. Even so,<br />

they can <strong>and</strong> do cause large locking issues. As a demonstration of the first point, if we have a<br />

pair of tables set up as follows:<br />

ops$tkyte@ORA10G> create table p ( x int primary key );<br />

Table created.<br />

ops$tkyte@ORA10G> create table c ( x references p );<br />

Table created.<br />

ops$tkyte@ORA10G> insert into p values ( 1 );<br />

1 row created.

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

Saved successfully!

Ooh no, something went wrong!