死锁问题总结

工作中经常会碰到一些ORA-00060的错误，这里给个总结：

[@more@]

1、如何解读相关TRACE文件
a.Current SQL statement for this session指的是接收到ORA-00060错误的会话正在执行的语句，该语句接收到错误后被回滚
b.对于TX模式的X锁，下面的信息说明session 10在等待object_id为3062的对象(to_number('BF6','XXXXXX')=3062)的ROWID
'AAAAv2AAEAAAAqKAAB'，session 11在等待object_id为3062的对象(to_number('BF6','XXXXXX')=3062)的ROWID 'AAAAv2AAEAAAAqKAAA'
Rows waited on:
Session 10: obj - rowid = 00000BF6 - AAAAv2AAEAAAAqKAAB
Session 11: obj - rowid = 00000BF6 - AAAAv2AAEAAAAqKAAA
从而可以定位到具体的数据。
c.对TM锁，ID1为OBJECT_ID，比如锁类型为TM-AAAAAAAA-BBBBBBBB，那么AAAAAAAA就是object_id的十六进制值
2、如何避免死锁
a.TX的X锁原因是应用的行级冲突，对行进行修改时需要遵循一定的顺序。
b.TX的S锁原因有很多
c.TM的SSX或S锁原因一般是外键约束中，子表的外键列上没有索引
3、其它
a.事务锁的几中情况举例
第一种是几个会话都试图去LOCK同一个ROW
第二种是唯一性约束情况下，两个会话DML后的数据会导致违反约束时
第三种是ITL slot不够用
可以用下面的语句查看ITL上的等待情况：
SELECT t.OWNER, t.OBJECT_NAME, t.OBJECT_TYPE, t.STATISTIC_NAME, t.VALUE
FROM v$segment_statistics t
WHERE t.STATISTIC_NAME = 'ITL waits'
AND t.VALUE > 0;
第四种是相同BITMAP index fragment所覆盖的行所引起的等待，下面是个例子
Eg: Ses#1: CREATE Bitmap Index tx_eg_bitmap on tx_eg ( sex );
Ses#1: update tx_eg set sex='FEMALE' where num=3;
Ses#2: update tx_eg set sex='FEMALE' where num=4;
DBA: select SID,TYPE,ID1,ID2,LMODE,REQUEST
from v$lock where type='TX';

SID TY ID1 ID2 LMODE REQUEST
---------- -- ---------- ---------- ---------- ----------
8 TX 262151 62 6 0
10 TX 327680 60 6 0
10 TX 262151 62 0 4

This shows SID 10 is waiting for the TX lock held by SID 8 and it
wants the lock in share mode (as REQUEST=4).
上面第二到第四种情况都是等待TX的S锁
b.外键列上加索引和不加索引情形下锁的情况
对子表的DML操作会对父表加MODE为4的TM锁
对父表的DML操作会对子表加MODE为4的TM锁，如果是deleting from the parent table with a delete cascade constraint，那么该锁的模式可能是SSX（LMODE=5）

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/85922/viewspace-1003617/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/85922/viewspace-1003617/