【IT168 技术文档】
介绍
本文我们尝试总结在多个用户并发情况下，如何识别和解决删除操作期间发生的死锁问题，在开始之前，我们先简单描述一下什么是死锁以及什么东西会导致死锁。
死锁
在任何数据库中发生死锁都是不愉快的，即使是在一个特殊的情况下发生也是如此，它们会减小应用程序的接受程度(ACCEPTANCE)，因此避免并正确解释死锁是非常重要的。
当两个或更多用户相互等待锁定的数据时就会发生死锁，发生死锁时，这些用户被卡住不能继续处理业务，Oracle自动检测死锁并解决它们(通过回滚一个包含在死锁中的语句实现)，释放掉该语句锁住的数据，回滚的会话将会遇到Oracle错误“ORA-00060：等待资源时检测到死锁”。
是什么导致了死锁?
明确地锁定表是为了保证读/写一致性，未建立索引的外键约束，在相同顺序下表不会锁住，没有为数据段分配足够的存储参数(主要是指INITTRANS，MAXTRANS和PCTFREE参数)很容易引发突发锁和死锁，原因是多种多样的，需要重新逐步审查。
识别死锁
当Oracle数据库检测到死锁时(Oracle错误消息：ORA-00060)，相应的消息就写入到警告日志文件中(alert.log)，另外还会在USER_DUMP_DEST目录下创建一个跟踪文件，分析警告日志文件和跟踪文件是非常耗时的。
下面是一个警告日志文件示例：
Mon Aug 07 09:14:42 2007
ORA-000060: Deadlock detected. More info in file
e:\oracle\admin\GEDEON\udump\ORA01784.TRC.
下面是从跟踪文件中节选出来的片段，从其中我们可以看出是哪个语句创造了死锁，相关的语句和被锁定的资源已经标记为粗体。
/users/ora00/log/odn_ora_1097872.trc
Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.8.0 - Production
ORACLE_HOME = /soft/ora920
System name:AIX
Node name:beaid8
Release:2
Version:5
Machine:00C95B0E4C00
Instance name: ODN
Redo thread mounted by this instance: 1
Oracle process number: 17
Unix process pid: 1097872, image: oracle@beaid8 (TNS V1-V3)
*** 2007-06-04 14:41:04.080
*** SESSION ID:(10.6351) 2007-06-04 14:41:04.079
DEADLOCK DETECTED ( ORA-00060 )
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:
Deadlock graph:
---------Blocker(s)-------- ---------Waiter(s)---------
Resource Name process session holds waits process session holds waits
TM-00001720-00000000 17 10 SX 16 18 SX SSX
TM-0000173a-00000000 16 18 SX 17 10 SX SSX
session 10: DID 0001-0011-00000002session 18: DID 0001-0010-00000022
session 18: DID 0001-0010-00000022session 10: DID 0001-0011-00000002
Rows waited on:
Session 18: obj - rowid = 00001727 - AAABcnAAJAAAAAAAAA
(dictionary objn - 5927, file - 9, block - 0, slot - 0)
Session 10: obj - rowid = 00001727 - AAABcnAAJAAAAAAAAA
(dictionary objn - 5927, file - 9, block - 0, slot - 0)
Information on the OTHER waiting sessions:
Session 18:
pid=16 serial=2370 audsid=18387 user: 21/ODN
O/S info: user: mwpodn00, term: unknown, ospid: , machine: beaida
program: JDBC Thin Client
application name: JDBC Thin Client, hash value=0
Current SQL Statement:
DELETE FROM ODNQTEX WHERE EX_ID = :B1
End of information on OTHER waiting sessions.
Current SQL statement for this session:
DELETE FROM ODNQTFN WHERE FN_ID_EXIGENCE_EX = :B1
----- PL/SQL Call Stack -----
object line object
handle number name
7000000135f7fd8 34 procedure ODN.ODNQPDR
7000000135f89f0 16 procedure ODN.ODNQPZB
我们可以使用企业管理器来决定保留所有的锁还是释放掉它们，为了便于说明，我们打开2个sqlplus实例会话(在此期间同时发生了死锁)来一起调式，当每个语句执行完毕后，我们看到锁仍然保留下来了，它可以帮助我们识别出是哪个资源引起的死锁。
下面列出了可以帮助我们监视锁的视图：
可以通过查询V$LOCK字典视图来确定锁，如：
select * from v$lock ;
下面的SQL查询可以用于确定锁住数据库对象的锁：
select
c.owner,
c.object_name,
c.object_type,
b.sid,
b.serial#,
b.status,
b.osuser,
b.machine
from
v$locked_object a ,
v$session b,
dba_objects c
where
b.sid = a.session_id
and
a.object_id = c.object_id;
