從oracle跟蹤文件中找到死鎖錯誤的原因

Question

當多個用戶正在使用應用程序時，我一直在我的應用程序中經常發現「在等待資源時檢測到ora-00060死鎖」錯誤。我從Oracle管理員那裏獲得了跟蹤文件，但在閱讀時需要幫助。以下是來自跟蹤文件的一些數據，我希望這將有助於查明原因。

*** 2013-06-25 09:37:35.324 
DEADLOCK DETECTED (ORA-00060) 

[Transaction Deadlock] 

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-000151a2-00000000  210  72 SX SSX  208  24 SX SSX 
TM-000151a2-00000000  208  24 SX SSX  210  72 SX SSX 

session 72: DID 0001-00D2-000000C6 session 24: DID 0001-00D0-00000043 
session 24: DID 0001-00D0-00000043 session 72: DID 0001-00D2-000000C6 

Rows waited on: 
Session 72: no row 
Session 24: no row 

----- Information for the OTHER waiting sessions ----- 
Session 24: 
sid: 24 ser: 45245 audsid: 31660323 user: 90/USER 
    flags: (0x45) USR/- flags_idl: (0x1) BSY/-/-/-/-/- 
    flags2: (0x40009) -/-/INC 
pid: 208 O/S info: user: zgrid, term: UNKNOWN, ospid: 2439 
    image: oracle@xyz.local 
client details: 
    O/S info: user: , term: , ospid: 1234 
    machine: xyz.local program: 
current SQL: 
    delete from EMPLOYEE where EMP_ID=:1 

----- End of information for the OTHER waiting sessions ----- 

Information for THIS session: 

----- Current SQL Statement for this session (sql_id=dyfg1wd8xa9qt) ----- 
delete from EMPLOYEE where EMP_ID=:1 
=================================================== 

如果有人能告訴我「Deadlock graph ::」在說什麼，我將不勝感激。此外，部分等待的行表示沒有行。

我還在一些博客中看到跟蹤文件中的「sqltxt」部分可以提示原因。以下是我在該部分看到的查詢。

select /*+ all_rows */ count(1) from "USERS"."EMPLOYEE_SALARY" where EMPSAL_EMP_ID=:1 

employee_salary表在EMPSAL_EMP_ID列上具有外鍵約束。

SQL提示說「all_rows」，那麼這是否表示從employee表中刪除記錄時此表獲取表級別鎖定？我目前在外鍵列上沒有索引。在這個列上添加索引有幫助嗎？

請注意，以防萬一需要更多信息。

感謝

Answer 1

首先，select聲明從未鎖定在甲骨文什麼，只是使用數據的最後一個可用的版本一致。 select ... for update自從Oracle 9i以來鎖定的數據類似於update，但在查詢中沒有for update子句。

Resource Name   process session holds waits process session holds waits 
TM-000151a2-00000000  210  72 SX SSX  208  24 SX SSX 

會話＃72保持表級鎖（TM）以「行排他」型（SX），並希望獲得「共享行排他」上相同的表（SSX）鎖。該會話被會話＃24阻止，該會話已經保存了同一類型的表級鎖（SX），並等待SSX鎖可用。

Resource Name   process session holds waits process session holds waits 
TM-000151a2-00000000  208  24 SX SSX  210  72 SX SSX 

該（第二行）表明完全相同的情況，但在相反的方向上：會話＃24等待SSX鎖變得可用，但按會話＃72已經保持於相同的表SX鎖阻塞。

因此，會話＃24和會話＃72彼此阻塞：發生死鎖。

兩種鎖類型（SX和SSX）都是表級鎖。
爲了解這種情況，我建議您閱讀Franck Pachot的this article。

下面是從這篇文章，這與您的情況直接相關的（注意，SSX和SRX縮寫是等同的）引文：

參照完整性也獲得TM鎖。例如，對於未索引的外鍵常見的 問題導致在子表上發生S鎖時， 您在父表上發出刪除或鍵上的更新。這是 ，因爲沒有索引，Oracle爲了防止可能違反參照完整性的併發插入，鎖定沒有單個較低級別資源到 。
如果外鍵列是常規索引中的前導 列，則第一個具有父代 值的索引條目可以用作單個資源並鎖定行級別TX 鎖定。
如果參照完整性具有刪除級聯，該怎麼辦？在 除S模式之外，還有打算更新 子表中的行，如同行X（RX）模式。這是共享行 獨佔（SRX）發生的位置：S + RX = SRX。

所以，最可能的變體是會話＃72和會話＃24在同一時間刪除EMPLOYEE表中的一些行，並有on delete cascade約束爲EMPSAL_EMP_ID結合不存在索引對EMPLOYEE_SALARY表，其中EMPSAL_EMP_ID柱首先列出。