關于“死鎖圖”（Deadlock Graph）的一點淺見
當 Oracle 檢測到死鎖時，檢測到死鎖的會話中的當前 SQL 將被取消，并執行“語句級回滾”，以釋放資源并避免阻塞所有活動。
檢測到死鎖的會話仍然“存活”，并且事務的其余部分仍然處于活動狀態。如果您在該會話中重復上次（被取消的）操作，那么您將再次遇到死鎖。
當檢測到此類死鎖時，會生成一個trace文件，其中包含“死鎖圖”（以及其他有用信息）。
通過對大量服務請求的審查，我們發現最常見的死鎖類型可以通過一個“特征”死鎖圖來識別，該圖可用于確定所遇到的死鎖的“類型”。
本文將展示每種類型的示例，以便調查和解決工作能夠沿著正確的方向進行。
這篇文章將說明如何利用由 ORA-00060 錯誤生成的“死鎖圖”（Deadlock Graph）來識別根本問題。
一個典型的死鎖圖可能看起來像這樣：
為了區分不同的類型，我們采用了鎖類型以及持有者和等待者所持有的/等待的模式，并以此為每個類型創建了一個簽名。
例如，前面的圖表顯示了以下特征：
- 死鎖圖中多于 1 行
- 所有鎖類型均為排他鎖（TX）
- 持有者和等待者的鎖模式均為 X（獨占模式，模式 6）
通過關注圖表中的這些特定特征：
將給我們以下類型（這通常是應用程序死鎖）：
TX X X Tx x x
TX X X Tx x x
請注意，對于死鎖類型識別而言，“關鍵簽名”中最重要的部分是鎖類型以及它所請求的模式。主要類型在下表中已突出顯示。
最常見的類型有：
Oracle 鎖模式有
0 - none 0—無
1 - null (NULL) 1 - null （null）
2 - 行共享，也稱為子共享表鎖（SS）
3 - 行排他表鎖，也稱為子排他表鎖（SX）
4 - 共享表鎖（S）
5 - 共享行排他鎖，也稱為共享子排他表鎖（SSX）
6 -排他(X)
注意：通常我們會看到應用程序死鎖的“特征”與其他特征之一的組合，而不是“典型”的重復特征。例如，您可能會看到類似這樣的內容：
死鎖圖---------Blocker(s)-------- ---------Waiter(s)---------
Resource Name process session holds waits process session holds waits
TM-XXXXXXXX-00000000 11 333 SX 22 44 SX SSX
TX-XXXXXXXX-XXXXXXXX 22 44 X 11 333 X
這是“應用程序死鎖”和“外鍵（FK）約束缺失索引”死鎖的組合。在這種情況下，建議先解決非“TX X X”的癥狀，因為不太常見的 FK/ITL/位圖簽名更有可能是根本原因，而不是應用程序死鎖。
請注意，trace 文件包含各種相關信息，這些信息可能與問題有關，也可能無關，這取決于死鎖的類型。
例如，在“Rows Waited on”部分，“dictionary objn”值在某些情況下可用于識別相關對象，但在其他情況下可能指向完全不相關的信息。
如果信息可用，會在相關部分注明，否則請勿依賴。
關于鎖定模式和鎖定的更多內容請見下文：
Oracle? Database Concepts
12c Release 1 (12.1)
E17633-20
Chapter 9 Data Concurrency and Consistency
https://docs.oracle.com/database/121/CNCPT/consist.htm#CNCPT020
參考文檔
Document 1552194.1 ORA-00060 Deadlock Graph Not Matching any Examples: Suggested Next Steps
Document 60.1 Troubleshooting Assistant: Oracle Database ORA-00060 Errors on Single Instance (Non-RAC) Diagnosing Using Deadlock Graphs in ORA-00060 Trace Files
How to Identify ORA-00060 Deadlock Types Using Deadlock Graphs in Trace (Doc ID 1507093.1)
Document 1559695.1 How to Diagnose Different ORA-00060 Deadlock Types Using Deadlock Graphs in Trace
