30.8.

2012

Deadlocks

Deadlocks
What are deadlocks? The "classic" deadlock What happens to both sessions? So, what's the fix? Deadlocks with Autonomous Transactions Deadlocks with Bitmap Indexes Deadlocks with unindexed foreign keys Detecting and identifying deadlocks Further information

What are deadlocks?

A deadlock is the situation where you have two, or more, Oracle "sessions" (well, transactional "states") competing for mutually locked resources. Oracle deals with deadlocks pretty much immediately by raising an exception (ORA-00060) in one of the sessions. There are a few reasons why your application may experience deadlocks, most of which are about application design. However, there are a few situations when, due to certain architectural design decisions, you may experience deadlocks simply due to the internal mechanisms of Oracle itself.

The "classic" deadlock

If session 1 is locking row 1, session 2 locks row 2, then session 1 attempts to lock row 2 (which will block since session 2 has the lock on that row), and then session 2 attempts to lock row 1 (which will block since session 1 has the lock on that row), then session 1 is waiting for session 2, and session 2 is waiting on session 1, which of course will never be resolved. Here's an actual Oracle example. First of all, setup the environment :
SL CET TBEt(avrhr(0 ) Q> RAE AL aca21) ; Tbecetd al rae. SL isr it tvle ('') Q> net no aus x ; 1rwcetd o rae. SL isr it tvle ('') Q> net no aus y ; 1rwcetd o rae. SL cmi; Q> omt Cmi cmlt. omt opee

Now, session 1 attempts to delete row 'x', but doesn't commit :

www.oratechinfo.co.uk/deadlocks.html 1/6

30.8.2012

Deadlocks

SS1 dlt fo tweea='' ES> eee rm hr x; 1rwdltd o eee.

Okay, now session 2 attempts to delete row 'y', again, not committing :
SS2 dlt fo tweea='' ES> eee rm hr y; 1rwdltd o eee.

Now, since session 2 has not committed the delete against row 'y', session 1 can still "see" it (and attempt to delete it) :
SS1 dlt fo tweea='' ES> eee rm hr y;

However, this will be blocked by session 2 (and hence wait), since row 'y' is locked, so session 1 is holding the lock on row 'x' but is waiting for row 'y'. Now, session 2 attempts to do it the "other way around", i.e. attempting to delete row 'x', while it retains the lock on row 'y' :
SS2 dlt fo tweea='' ES> eee rm hr x;

this will be blocked by session 1 (and hence wait). So, the situation is tied, session 2 is waiting for session 1 and session 1 is waiting for session 2. So, in reality, what happens in this situation? Well, obviously deadlocks just simply can't be allowed to occur, it's basically an infinite loop, the situation can't be resolved. So, Oracle steps in, automatically detecting the deadlock and resolving it by causing one of the sessions (can't actually guarantee which one) to receive an ORA-00060 error, i.e.
OA000 dalc dtce wiewiigfrrsuc R-06: edok eetd hl atn o eore

What happens to both sessions? So, we've seen what happens in terms of the deadlock, one of the sessions will error with the ORA-00060 error, but what about the other one? Well, this may be surprising to some people, but it carries on waiting, because the ORA-00060 error in the other session does not commit or rollback, and hence it retains it's previous lock(s), including those involved in the deadlock scenario. It is the responsibility of the client to commit or rollback if an ORA-00060 error is encountered. So, what's the fix? As with all deadlock scenarios, it's about avoidance rather than remedy. For the classic deadlock situation, you have to ensure that sessions do their operations in the same "order", i.e. if a process updates table t1 then t2, that any other process does so in the same order.

Deadlocks with Autonomous Transactions

As mentioned in the previous section, all deadlocks are variations on the same theme, i.e. multiple "sessions" competing for mutually locked resources. Since an Autonomous Transaction (AT) is basically a "session within a session", it's perfectly possible for it to occur here as well. This is maybe a little less obvious, since some people think that somehow they're part of the same "parent" session, but this is not the case. Note, however, that a deadlock is slightly more subtle when using ATs :
www.oratechinfo.co.uk/deadlocks.html 2/6

30.8.2012

Deadlocks

Showing this is trivial. First, create an AT process :

SL CET O RPAEPOEUEpa Q> RAE R ELC RCDR _t 2 A S 3 PAM ATNMU_RNATO; RGA UOOOSTASCIN 4 BGN EI 5 DLT FO t EEE RM ; 6 CMI; OMT 7 EDpa; N _t 8 / Poeuecetd rcdr rae.

Now, put a single row into a table :

SL isr it tvle ('') Q> net no aus x ; 1rwcetd o rae. SL cmi; Q> omt Cmi cmlt. omt opee

Now, delete the row in the "parent" session :

SL dlt fo t; Q> eee rm 1rwdltd o eee.

Now, since the "parent" session is locking the row in "t", any attempt to delete it via an AT from within the "parent" session, will result in ORA-00060, i.e.
SL ee pa; Q> xc _t BGNpa;ED EI _t N; * ERRa ln 1 RO t ie : OA000 dalc dtce wiewiigfrrsuc R-06: edok eetd hl atn o eore OA052 a "ATNPA" ln 5 R-61: t MRI._T, ie OA052 a ln 1 R-61: t ie

So, why does the AT simply not block on the 'x' row? Well, if it did, imagine the situation, "parent" session is waiting for the AT to "finish" (like any other PL/SQL call), but it never will since it's blocked waiting for it's parent session to commit or rollback.

Deadlocks with Bitmap Indexes

Bitmap indexes were designed to be used solely within data warehouses, i.e. where the vast majority of the database activity is reading data, and there's very little (or no) data modification, except for batch processes which occasionally re-populate the warehouse. Each "row" in the bitmap index contains references to potentially many different rowids, in contrast to a B*-tree index which references a single rowid. It should be obvious, therefore, that, since the transactional mechanism is the same for all database operations, that any DML on a table which impacts the bitmap index may end up locking (or attempting to lock) many different "rows" within the index. This is the key concept with deadlocks in bitmap indexes, you're not being deadlocked on the underlying table, but on the index blocks. The ability of an INSERT statement to deadlock (which is usually impossible) is therefore explained in that
www.oratechinfo.co.uk/deadlocks.html 3/6

30.8.2012

Deadlocks

the bitmap index is maintaining other rows as a result of the DML. Fortunately, it's easy to detect these kind of deadlocks, because the trace file has a very particular format :
Dalc gah edok rp: -----lce()---- -----atrs--------Bokrs-------Wie()---Rsuc Nm eore ae poesssinhlswis poesssinhlswis rcs eso od at rcs eso od at T-080700da X0002-0021 1 2 3 7 X 1 5 3 5 S T-0a0600dd X0001-0062 1 5 3 5 X 1 2 3 7 S ssin3:DD00-0C0000 ssin3:DD00-0F0000 eso 7 I 0100-0002 eso 5 I 0100-0002 ssin3:DD00-0F0000 ssin3:DD00-0C0000 eso 5 I 0100-0002 eso 7 I 0100-0002 Rw wie o: os atd n Ssin3:n rw eso 5 o o Ssin3:n rw eso 7 o o

Note, the "no row" entries. This is the prime indicator that this is a bitmap index deadlock. There's very little you can do about this, apart from not use bitmap indexes in a DML environment.

Deadlocks with unindexed foreign keys

There are various attributes which can be specified when creating foreign key constraints. The ones of interest are UPDATE and DELETE CASCADE. These attributes define what happens to the child record(s) when various actions are performed on the parent record. The upshot of the deadlock problem is that in these situations (i.e. using the UPDATE or DELETE CASCADE options of the FK constraint), without an index on the foreign key column(s), Oracle has no option but to attempt to get a table lock on the child table while it performs it's maintenance. In this situation, it's obvious that the potential for deadlocking is vastly increased for having to lock the whole child table. Fortunately, resolving this is quite straightforward, you simply put an index on the foreign key column(s). So, is there any way of being proactive about this, and identifying the table(s) / column(s) which are the subject of a foreign key constraint, but do not have indexes? Yes, Tom Kyte has written one and it's located here. For more information about this problem (and other performance related issues regarding unindexed FKs), see http://asktom.oracle.com/~tkyte/unindex/index.html.

Detecting and identifying deadlocks

Well, the obvious way of detecting a deadlock is when you see the ORA-00060 error, however, sometimes ( especially with complex applications ), it may not be obvious what is actually causing the deadlock itself. Fortunately, whenever a deadlock occurs, Oracle creates a trace file (in user_dump_dest), with information which will allow you to see details about the deadlock, what the shared resource is, what the current SQL statement was, etc. etc. Here's an extract from the trace file generated on a 10g Express Edition (XE) from the above first deadlock situation above. Note, the full trace file contains a lot more information for the developer / DBA to utilise to determine the exact cause of the situation which caused the deadlock.

www.oratechinfo.co.uk/deadlocks.html

4/6

30.8.2012

Deadlocks

Trace file extract from two distinct Oracle sessions

**20-10 1:91.2 * 061-5 32:691 **ATO NM:)20-10 1:91.0 * CIN AE( 061-5 32:696 **MDL NM:SLPu)20-10 1:91.0 * OUE AE(Q*ls 061-5 32:696 **SRIENM:SSUES 20-10 1:91.0 * EVC AE(Y$SR) 061-5 32:696 **SSINI:2.)20-10 1:91.0 * ESO D(75 061-5 32:696 DALC DTCE EDOK EETD [rnato Dalc] Tascin edok CretSLsaeetfrti ssin urn Q ttmn o hs eso: dlt fo tweea='' eee rm hr x Tefloigdalc i nta OAL err I i a h olwn edok s o n RCE ro. t s dalc det ue erri tedsg o a apiain edok u o sr ro n h ein f n plcto o fo isigicreta-o SL Tefloig r rm sun norc dhc Q. h olwn ifrainmyadi dtriigtedalc: nomto a i n eemnn h edok Dalc gah edok rp: -----lce()---- -----atrs--------Bokrs-------Wie()---Rsuc Nm eore ae poesssinhlswis poesssinhlswis rcs eso od at rcs eso od at T-07030009 X0002-000c 1 8 2 7 X 2 0 3 8 X T-06010008 X0002-000d 2 0 3 8 X 1 8 2 7 X ssin2:DD00-020001 ssin3:DD00-040000 eso 7 I 0101-0001 eso 8 I 0101-0005 ssin3:DD00-040000 ssin2:DD00-020001 eso 8 I 0101-0005 eso 7 I 0101-0001 Rw wie o: os atd n Ssin3:oj-rwd=0034 -AAVAEAAPA eso 8 b oi 005E ADOAAAAAB (itoayoj -166 fl -4 bok-1,so -1 dcinr bn 34, ie , lc 5 lt ) Ssin2:oj-rwd=0034 -AAVAEAAPA eso 7 b oi 005E ADOAAAAAA (itoayoj -166 fl -4 bok-1,so -0 dcinr bn 34, ie , lc 5 lt )

Note, the fragment (dictionary objn - 13646, file - 4, block - 15, slot - 1), the objn - 13646 relates to the object_id, which can be queried via dba_objects or similar. Trace file extract for same session with Autonomous Transaction
**20-10 1:42.2 * 061-5 40:038 **ATO NM:)20-10 1:42.2 * CIN AE( 061-5 40:038 **MDL NM:SLPu)20-10 1:42.2 * OUE AE(Q*ls 061-5 40:038 **SRIENM:SSUES 20-10 1:42.2 * EVC AE(Y$SR) 061-5 40:038 **SSINI:2.6 20-10 1:42.2 * ESO D(72) 061-5 40:038 DALC DTCE EDOK EETD [rnato Dalc] Tascin edok CretSLsaeetfrti ssin urn Q ttmn o hs eso: DLT FO T EEE RM ---P/Q Cl Sak---- LSL al tc -ojc bet ln ojc ie bet hnl ade nme nm ubr ae 29D3 0D68 5 poeueMRI._T rcdr ATNPA 1156 DC6C 1 aoyosbok nnmu lc Tefloigdalc i nta OAL err I i a h olwn edok s o n RCE ro. t s dalc det ue erri tedsg o a apiain edok u o sr ro n h ein f n plcto o fo isigicreta-o SL Tefloig r rm sun norc dhc Q. h olwn ifrainmyadi dtriigtedalc: nomto a i n eemnn h edok Dalc gah edok rp: -----lce()---- -----atrs--------Bokrs-------Wie()---Rsuc Nm eore ae poesssinhlswis poesssinhlswis rcs eso od at rcs eso od at T-08030009 X0000-0001 1 8 2 7 X 1 8 2 7 X ssin2:DD00-020001 ssin2:DD00-020001 eso 7 I 0101-000E eso 7 I 0101-000E Rw wie o: os atd n Ssin2:oj-rwd=0034 -AAVAEAAPA eso 7 b oi 005E ADOAAAAAA (itoayoj -166 fl -4 bok-1,so -0 dcinr bn 34, ie , lc 5 lt )
www.oratechinfo.co.uk/deadlocks.html 5/6

30.8.2012

Deadlocks

As you can see, Oracle does a good job of giving as much information about the involved sessions (including "current" SQL statement, etc.).

Further Information
The issue of deadlocks (and how to deal with them) is quite an extensive subject, and there are plenty of web resources for understanding them. Note, the Oracle Metalink links require a metalink account to access.
Ask Tom : Determining which query caused deadlock. Metalink 164661.1 : ORA-60 / Deadlocks Most Common Causes Metalink 171795.1 : Bitmap Indexes and Deadlocks: Deadlocks on Insert Statements Metalink 62365.1 : What to do with "ORA-60 Deadlock Detected" Errors

www.oratechinfo.co.uk/deadlocks.html

6/6