本文闡述了開發人員和測試人員如何確定 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。105DBID/OBID for database and tablespace translation　107Data set open/close information172Deadlock在 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：16Start of the first insert20Lock summary　53Describe, SQL commit/rollback or error before SQL analyzed58End of SQL statement execution59Start of FETCH　60start of SELECT61Start of INSERT, UPDATE or DELETE63SQL statement to be parsed　64start of PREPARE65start of OPEN CURSOR for static or dynamic SQL　66Start of CLOSE CURSOR for static or dynamic SQL　68Start of ROLLBACK69End of ROLLBACK　70Start of COMMIT phase 2　71End of COMMIT phase 288start of synchronous request (commit phase 1)89End of synchronous request (commit phase 1)　105DBID/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 鎖）死鎖時間表0CC544053119SW03DB1.USERS.X'00004E'.X'2B'SW03DB1.USERS.X'00004C'.X'2B'06:30:09.410449910E26A4053107SW03DB1.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 0CC544053119COMMIT RECEIVED　06:28:50.72COMMIT RECEIVED　06:28:50.85COMMIT RECEIVED　06:28:50.97COMMIT RECEIVED　06:28:51.04the latest commit before the deadlock occurred.COMMIT RECEIVED　06:30:09.61COMMIT RECEIVED　06:30:09.64COMMIT RECEIVED　06:30:09.73COMMIT RECEIVED　06:30:09.77COMMIT 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 0E26A4053107COMMIT RECEIVED 06:28:50.65the 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 語句，并完成并發性能問題解決方案的第一步。