：enqueue deadlocks，library cache deadlocks.
http://yong321.freeshell.org/computer/deadlocks.txt
There're two common deadlocks. ORA-60, enqueue deadlocks; ORA-4020, library
cache deadlocks.
********** ORA-60 **********
Reproduction:
This is very easy to reproduce. Just follow this procedure:
In sessionA, update tb set col = 'x' where pk = 'aa'
In sessionB, update tb set col = 'x' where pk = 'bb'
In sessionA, update tb set col = 'x' where pk = 'bb'
In sessionB, update tb set col = 'x' where pk = 'aa'
If neither session commits, 3 seconds after the last statement shown above is
issued, sessionA will throw error ORA-60, with the corresponding deadlock graph
generated in the udump trace file:
---------Blocker(s)-------- ---------Waiter(s)---------
Resource Name process session holds waits process session holds waits
TX-00010017-000000ba 8 7 X 9 8 X
TX-00020012-000000af 9 8 X 8 7 X
session 7: DID 0001-0008-00000002 session 8: DID 0001-0009-00000002
session 8: DID 0001-0009-00000002 session 7: DID 0001-0008-00000002
Rows waited on:
Session 8: obj - rowid = 00000CBB - AAAAzjAADAAAAFDAAA
Session 7: obj - rowid = 00000CBB - AAAAzjAADAAAAFDAAB
Interpretation:
Resource here simply means lock as in v$resource (technically it should be the
locked resource). TX stands for transaction, usually row lock. The numbers that
follow are v$lock.id1, v$lock.id2, respectively, in hex radix for TX enqueue.
E.g., 20012[hex] is 131090; ba[hex] is 175. Anjo Kolk's Wait Event paper
(Description of Oracle7 Wait Events and Enqueues, used to be at
www.dbatoolbox.com/WP2001/dbamisc/events.pdf) tells us that id1 is "undo
segment number << 16 | slot". Indeed we find v$transaction.xidusn = 2 and
x$transaction.xidslot = 18. So 10[bin] left shifted 16 bits ORed with 18 equals
131090. id2 should be "sequence"; v$transaction.xidsqn = 175. Process is
Oracle process ID (not to be confused with the OS level process ID in UNIX or
thread ID in Windows); it is v$process.pid where v$process.addr matches
v$session.paddr. Session is v$session.sid. X means it's holding or waiting for
an exclusive lock. DID is deadlock ID (see Note:6145177.8); the first number is
always 1; second number is Oracle process ID; I don't know the third number.
For sessions waiting for row locks, additional
information about the rows is given. CBB[hex] is dba_objects.object_id from
which you'll know the table. Then the rowid is given so that you can quickly
find the row by SELECT * FROM thetable WHERE ROWID = 'rowid'. If the "Rows
waited on" is followed by "no rows", then it's waiting on a table lock, not a
row lock, like in this case:
---------Blocker(s)-------- ---------Waiter(s)---------
Resource Name process session holds waits process session holds waits
TX-00060004-00003155 41 45 X 15 26 S
TX-0012000b-00002802 15 26 X 41 45 S
session 45: DID 0001-0029-00000002 session 26: DID 0001-000F-00000002
session 26: DID 0001-000F-00000002 session 45: DID 0001-0029-00000002
Rows waited on:
Session 26: no row
Session 45: no row
Following the deadlock graph is process state dump, which shows state object
(SO) hierarchy in properly indented form, with the root being a process SO.
Remedy:
If the "Session <SID>" line gives row IDs, simply wait and rerun the
application later. And consider application design to see if you have two
programs updating the same table but in different order. [note1]
If the Session line says "no row", the error could be triggered when multiple
sessions try to update the same block while the free space for the block is
already too small for Oracle to automatically increase ITLs (interested
transaction lists), regardless the value of MAXTRANS. You can try rebuilding
the table with a higher INITRANS (initial ITL entries) and setting a higher
value of PCTFREE. Beginning with 8i, the easiest way to do this is ALTER TABLE
yourtable MOVE STORAGE (INITRANS xxx).
Another scenario which does happen often is that you don't have indexes on
child table foreign key columns and multiple sessions are updating the parent
table primary key columns or deleting rows from the parent table. Both sessions
will attempt to acquire a shared table lock on the child table and if they
already hold row locks (on different rows), a deadlock results. In this case,
you may build indexes on foreign keys in the child table. Numerous sites
provide scripts to find foreign keys that are missing indexes
(osi.oracle.com/~tkyte/unindex/ and www.jlcomp.demon.co.uk/faq/fk_ind.html). If
you don't do this (possibly for legitimate reason such as child table DML
performance), make sure you never or rarely delete rows from the parent table
(updating parent table primary keys is very rare). Or as Steve Adams suggested,
ALTER TABLE childtable DISABLE TABLE LOCK.
Further reading: Metalink Note:62365.1
********** ORA-4020 **********
Reproduction:
SQL> create procedure p1 as begin p2; end;
2 /
Warning: Procedure created with compilation errors.
SQL> create procedure p2 as begin p1; end;
2 /
Warning: Procedure created with compilation errors.
SQL> alter procedure p1 compile;
alter procedure p1 compile
*
ERROR at line 1:
ORA-04020: deadlock detected while trying to lock object YONG.P1
The above case is modified from an example in Connor McDonald's "Mastering
Oracle PL/SQL: Practical Solutions". Obviously, you can't have mutual library
cache locks in each other's code.
More commonly, this error is thrown due to invalid objects especially triggers,
or due to Oracle bugs. E.g., Jonathan Lewis in "Practical Oracle8i" reported
that query throws ORA-4020 if partitioned IOT maintenance is going on. An
ORA-4020 deadlock graph looks like the following:
ORA-04020: deadlock detected while trying to lock object YONG.P1
--------------------------------------------------------
object waiting waiting blocking blocking
handle session lock mode session lock mode
-------- -------- -------- ---- -------- -------- ----
797992F8 7AA06C48 79FA5554 X 7AA06C48 79F8B3D0 X
--------------------------------------------------------
Note that in this case, the waiting session is the same as the blocking session
because they have the same session address.
Remedy:
If the deadlock is caused by the same session that experiences the deadlock,
make sure you don't have any invalid objects on the table reported in the
deadlock trace file, such as invalid triggers. If you do, manually compile
them. With this deadlock, it's helpful to get more insight by tracing the event
4020 as follows: alter session set events '4020 trace name processstate
forever, level 10'; or if you don't know or can't access the session, put
event='4020 trace name processstate forever, level 10' in init.ora file and
bounce the database. The trace file thus created when the deadlock occurs next
time may have strings like "status=INVL". Look at the corresponding object name
after "name=". If you do experience ORA-4020 and it happens fairly often, search
on Metalink or open a tar.
********** Deadlocks in RAC **********
There's no error number reported but both ORA-60 and ORA-4020 are possible. In
alert.log, we only see "Global Enqueue Services Deadlock detected. More info in
filen /home/oracle/admin/<SID>/bdump/<SID>_lmd0_<pid>.trc." ["filen" is not
typo; it means "file name".]
LMD trace file has:
user session for deadlock lock 0x7553ab14
pid=33 serial=37657 audsid=6450105 user: 246/<LinuxUsername>
O/S info: user: <WindowsUsername>, term: MISFBB10-54, ospid: 4148:5156, machine: <NTdomain>\<PCname>
program: sqlplus.exe
application name: SQL*Plus, hash value=3669949024
Current SQL Statement:
update test set a = :"SYS_B_0" where a = :"SYS_B_1"
Global Wait-For-Graph(WFG) at ddTS[0.28] :
BLOCKED 0x7553ab14 5 [0xf001d][0x8353],[TX] [2162689,7995] 0
BLOCKER 0x69cabb5c 5 [0xf001d][0x8353],[TX] [1769474,4478] 1
BLOCKED 0x69cabc30 5 [0x70014][0xe908],[TX] [1769474,4478] 1
BLOCKER 0x7e1424e8 5 [0x70014][0xe908],[TX] [2162689,7995] 0
That was Oracle 9.2.0.7.0 on Linux accessed from a Windows PC. According to
Note:262226.1, the first process in instance 0 (on the first line) requested for
a TX lock in mode 5 or exclusive [note2] and was blocked by the second process in
instance 1 (on the second line), which requested for another TX lock (third
line) and was blocked by the first process (fourth line). The note interprets
the numbers after the lock name, e.g. [2162689,7995], as process ID. But if
there're two numbers in square brackets, those two numbers are transaction_id0
and transaction_id1 of v$ges_blocking_enqueue, respectively, or equivalently
the same columns in v$dlm_locks. (But I don't know what the transaction number
means; it doesn't seem to be concatenation of xidusn.xidslot.xidsqn of
v$transaction.) In addition, the hex numbers following "BLOCKED" or "BLOCKER"
are handles (lock pointers) of v$ges_blocking_enqueue, and the two hex numbers
after lock mode are id1 and id2 in v$lock (refer to
http://yong321.freeshell.org/oranotes/LocksWhere2FindMoreInfo.txt on how to
find their meanings).
The above trace shows the SQL involved in the deadlock. But in some cases, the
SQL is missing,[note3] as in this example:
Global Wait-For-Graph(WFG) at ddTS[0.15] :
BLOCKED 0x70d17058 5 [0xf4dd2a46][0x57e4077],[LB] 30268 0
BLOCKER 0x70d16594 5 [0xf4dd2a46][0x57e4077],[LB] 30268 0
This deadlock was caused by B-namespace library cache lock requested and
blocked by itself. The process PID is 30268 (a single number, not in brackets).
Unfortunately it's missing the SQL. Note:262226.1 acknowledges that it would be
more helpful to add the SQL to the WFG trace. In the meantime, if the deadlock
can be reproduced with one instance (as in this case because the last column,
instance number, is the same number), then do so by setting cluster_database
to false; a deadlock graph in a non-cluster database is much more useful than a
global WFG, which is created even if all involved processes are on one node.
Yong Huang
[email protected]
________________________
[note1]
It's often suggested that applications should be written in a way to ensure the
same order in running DMLs on the table. This means ProgramI should update
tblX then tblY and ProgramII should also update them in this order. But
there're many other cases than this rule should apply. Consider this case:
if conditionA, update tblX
if conditionB, update tblY
if conditionC, update tblX
if conditionD, update tblY
If this single program (no ProgramII) is run by multiple processes, depending
on the conditions met in each process, a deadlock could occur.
[note2]
According to
http://www.rachelp.nl/index_kb.php?menu=articles&actie=show&id=15
these mode numbers start with 0. So mode 5 here means exclusive, which would
be mode 6 in non-RAC lock mode.
[note3]
According to Dusan Bolek (message 10 of
http://groups.google.com/group/comp.databases.oracle.server/browse_frm/thread/a1e9aacfc4e16e25/),
the SQL is present if the deadlock occurs between instances and missing if
on the same instance.
ORA-12829
ORA-99
12345678901234567890123456789012345678901234567890123456789012345678901234567890