選擇數據類型 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 |
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 語句，并完成并發性能問題解決方案的第一步。 新聞熱點
疑難解答
