本文闡述了開發人員和測試人員如何確定 DB2 for z/OS 環境下復雜 Web 應用程序中的死鎖原因。
簡介
在任何數據庫環境中，死鎖檢測對於應用程序並發性都是很重要的。就像其他應用程序一樣，在復雜 Web 環境中也需要能夠確定任何死鎖的起因。本文解釋了如何配置 DB2 for os/390 的死鎖跟蹤設置，以啟用死鎖分析。先闡述了如何指定相關的 DB2 for z/OS 跟蹤以獲取足夠信息，然後說明如何分析這些跟蹤報告，並指出引起 DB2 for z/OS 環境中運行的復雜 Web 應用程序出現死鎖的不良 SQL 語句。本文假定讀者熟悉基本的 z/OS 操作。
使用 DB2 Performance Monitor 來配置跟蹤
Locking 跟蹤
若要啟用 Locking 跟蹤，首先打開 IBM DB2 Performance Monitor 應用程序。然後執行下面步驟：
配置 Collect Task A 以收集死鎖跟蹤。設置 Trigger by 4=Immediate Start 以立即激活任務。
選擇 Locking, Data Type, IFICD, Requesting Location, Plan name and Authid，然後按 Enter。
圖 1. 配置 Collect Task A
選擇數據類型 Lockout，然後按 Enter。
在 IFCID Selection 面板中，選擇下面的 IFICD，然後按 Enter。105 DBID/OBID for database and tablespace translation
107 Data set open/close information
172 Deadlock
在 Trace Qualification 面板中，填入 DB 用戶名（在本例中為 TUSER03）和 DB 模式（在本例中為 TGUSER03），然後按 Enter。
圖 2. Trace qualification 面板
在 Trigger Immediately 面板中，填入 DB2 跟蹤數據的輸出數據集（例如，TGUSER03.DB2PM.TRACE01）。設置 Disposition 為 Overwrite。
注意：可以使用其他方法來配置 DB2 跟蹤停止觸發器（例如，經過一段時間後）。
圖 3. Trigger immediately 面板
按 Enter，完成 Locking 跟蹤配置。
如果 Web 應用程序運行期間有死鎖，則激活 Collect Task A 來收集死鎖信息。
SQL Activity 跟蹤
按照下面步驟來配置 SQL Activity 跟蹤：
配置 Collect Task B 以收集 SQL Activity 跟蹤。設置 Trigger by 4=Immediate Start 來立即激活任務。
選擇 SQL Activity, Data Type, IFCID, Requesting Location, Plan name and Authid，然後按 Enter。
選擇全部收集數據類型，然後按 Enter。
在 IFCID Selection 面板中，選擇下面的 IFCID，然後按 Enter：16 Start of the first insert
20 Lock summary
53 Describe, SQL commit/rollback or error before SQL analyzed
58 End of SQL statement execution
59 Start of FETCH
60 start of SELECT
61 Start of INSERT, UPDATE or DELETE
63 SQL statement to be parsed
64 start of PREPARE
65 start of OPEN CURSOR for static or dynamic SQL
66 Start of CLOSE CURSOR for static or dynamic SQL
68 Start of ROLLBACK
69 End of ROLLBACK
70 Start of COMMIT phase 2
71 End of COMMIT phase 2
88 start of synchronous request (commit phase 1)
89 End of synchronous request (commit phase 1)
105 DBID/OBID for database and tablespace translation
在 Trace Qualification 面板中，填入 DB 用戶名（例如，TUSER03）和 DB 模式（例如，TGUSER03），然後按 Enter。
在 Trigger Immediately 面板中，填入 DB2 跟蹤數據的輸出數據集（例如，TGUSER03.DB2PM.TRACE02）。設置 Disposition 為 Overwrite。
注意：可以使用其他方法來配置 DB2 跟蹤停止觸發器（例如，經過一段時間後）。
按 Enter 完成 SQL Activity 配置。
在 Web 應用程序運行期間，激活 Collect Task B 來收集 SQL 語句。
分析跟蹤報告以確定不良 SQL 語句
Web 應用程序中 DB2 鎖的原理
通常 Web 應用程序有頁鎖和行鎖。根據創建數據庫所使用的數據定義語言 (DDL) 模式文件，可以確定正在使用的鎖類型。行鎖有三種模式：S(Share)、U(Update) 和 X(Exclusive)。要盡量避免的鎖影響是掛起、超時和死鎖。
當兩個或兩個以上應用程序進程均持有對資源（該資源是其他進程所需，且沒有該資源時進程無法繼續進行）的鎖時，會發生死鎖。下面是關於發生死鎖情況的詳細解釋：
JobOne 和 JobTwo 是兩個事務。JobOne 訪問表 M，並持有頁 B 的 X (exclusive) 鎖，包含記錄 000300。
JobTwo 訪問表 N，並持有頁 A 的 X (exclusive) 鎖，包含記錄 000010。
JobOne 請求表 N 頁 A 的鎖，同時仍持有表 M 頁 B 的鎖。因為 JobTwo 持有頁 A 的 X 鎖，所以作業被掛起。
JobTwo 請求表 M 頁 B 的鎖，同時仍持有表 N 頁 A 的鎖。因為 JobOne 持有頁 B 的 X 鎖，所以作業被掛起。這種情況就是死鎖。
為了改善應用程序的並發性，您需要找到引起死鎖的 SQL 語句。然後，優化 SQL 語句以消除死鎖。
根據死鎖報告來分析鎖信息
作為例子，我們假定當多個顧客同時登錄並注冊一個商店時發生死鎖。您已經得到死鎖跟蹤報告和 SQL 語句報告。
首先，您應檢查死鎖跟蹤報告（在本文中為 TGUSER03.DB2PM.LOCKS）。
下面是跟蹤報告中一些關鍵參數的說明，有助於理解該進程：
圖 4. 跟蹤參數
分析一下表 USERS（圖 5 和圖 6）上的第一個死鎖。在圖 5 中，可以看到死鎖涉及到兩個資源。分別是 row X'2B'、page X'00004E'、page USERS、DB SW03DB1 和 row X'2B'、page X'00004C'、table USERS、DB SW03DB1。WAITERS =2 表明死鎖中有兩個等待者（0CC544053119 和 0E26A4053107）。死鎖發生在 12/05/05 06:30:09.40。
從圖 6 可以看到資源持有者和等待者與圖 5 中的相反。等待者（實際上是圖 5 中的持有者）正在請求持有者（實際上是圖 5 中的等待者）所持有的資源。按照死鎖的定義，在這種情況下會發生死鎖。
現在，利用圖 5 和圖 6 來總結一下鎖關系。
從圖 5 中可以看到 LUW 0CC544053119 所持有的鎖是 row X'2B'、page X'00004E'、table USERS、DB SW03DB1 上的行鎖，且保持在 X 狀態。等待者 LUW 實例 0E26A4053107 正在請求同一個資源上的 S 鎖模式。而在圖 6 中，LUW 0E26A4053107 所持有的鎖是 row X'2B'、page X'00004C'、table USERS、DB SW03DB1 上的行鎖，且保持在 X 狀態。等待者 LUW 實例 0CC544053119 正在請求同一個資源上的 S 鎖模式。因此發生死鎖。
最後，請注意圖 5 中的 BLOCKER is HOLDER --*VICTIM*，該線程 ("victim") 的作用是回滾以進行其他線程。
圖 5. Locking 跟蹤 —— 死鎖報告
圖 6. Locking 跟蹤 —— 死鎖報告
表 1 總結死鎖分析：
表 1. 死鎖分析
LUW 實例 持有的資源（X 鎖） 請求的資源（S 鎖） 死鎖時間表 0CC544053119 SW03DB1.USERS.X'00004E'.X'2B' SW03DB1.USERS.X'00004C'.X'2B' 06:30:09.41044991 0E26A4053107 SW03DB1.USERS.X'00004C'.X'2B' SW03DB1.USERS.X'00004E'.X'2B' 06:30:09.41044991根據 SQL 活動報告來分析 SQL 信息
打印 SQL ACTIVITY 跟蹤（在本文中為 TGUSER03.DB2PM.SQL），使用死鎖所涉及的 LUW INSTANCE 數量(0CC544053119 和 0E26A4053107）進行過濾。可以發現最後一次 commit 操作應正好在死鎖出現 (06:30:09.41044991) 前完成。接下來，搜索僅在完成最後一次 commit 操作後執行的 SQL 語句。
COMMIT processing in SQL ACTIVITY trace for INSTANCE 0CC544053119
COMMIT RECEIVED 06:28:50.72
COMMIT RECEIVED 06:28:50.85
COMMIT RECEIVED 06:28:50.97
COMMIT RECEIVED 06:28:51.04 the latest commit before the deadlock occurred.
COMMIT RECEIVED 06:30:09.61
COMMIT RECEIVED 06:30:09.64
COMMIT RECEIVED 06:30:09.73
COMMIT RECEIVED 06:30:09.77
COMMIT RECEIVED 06:30:09.80
因此，應該研究那些訪問過 SW03DB1.USERS 且在 06:28:51.04 到 06:30:09.41044991 之間執行的 SQL 語句。如圖 7 所示。
圖 7. SQL 報告
根據鎖狀態 X 和 S，對於資源 SW03DB1.USERS，在 SELECT 語句之前應是 INSERT 語句。
按照同樣的方法，對於 INSTANCE 0E26A4053107，可以找到在出現死鎖前進行最後一次 commit 的時間.
COMMIT processing in SQL ACTIVITY trace for INSTANCE 0E26A4053107
COMMIT RECEIVED 06:28:50.65 the latest commit before the deadlock occurred.
COMMIT RECEIVED 06:30:49.67
然後，研究那些訪問過 SW03DB1.USERS 且在 06:28:50.65 到 06:30:09.41044991 之間執行的 SQL 語句。如圖 8 所示。
圖 8. SQL 報告
從圖 5 和圖 6 中可以看到兩個實例 0CC544053119 和 0E26A4053107 正嘗試提交 INSTER INTO USERS 和 SELECT FROM USERS SQL 語句。由於 INSERT 和 SELECT 語句之間沒有 COMMIT，死鎖可能是由表掃描引起的。因此運行並發線程時，出現了死鎖。
結束語
本文闡述了如何使用 DB2 Performance Monitor 工具來收集死鎖和 SQL Activity 跟蹤。另外，給出了一個例子，演示如何通過分析跟蹤找到一個死鎖情況所涉及的 SQL 語句。使用該方法，開發人員和測試人員都可以發現不良 SQL 語句，並完成並發性能問題解決方案的第一步。
