死鎖問題總結

工作中經常會碰到一些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）