DB2 9.5 鎖超時根因分析進階：鎖超時報告與語句歷史深度實戰（下）

核心升級：從「最後一條語句」到「完整事務歷史」

DB2 9.5 引入 鎖超時報告 與 死鎖事件監視器 (DETAILS HISTORY)，徹底解決舊版 db2cos + db2pd 僅能捕獲鎖持有者「最後一條語句」的盲區——最後一條語句往往只是查詢，真正持有衝突鎖的 UPDATE/DELETE 早已執行完畢隱藏在事務歷史中。

鎖超時報告關鍵字段解讀

報告分三大塊：請求者、鎖信息、持有者。重點字段：

實戰案例還原

場景

• 請求者：執行 UPDATE EMPLOYEE SET BONUS = SALARY * 0.1 WHERE JOB = 'MANAGER' 申請 U 鎖超時。
• 持有者：同一用戶另一會話，持有同一行 X 鎖。
• 舊工具只能看到持有者最後執行 SELECT LASTNAME, FIRSTNME, SALARY FROM EMPLOYEE ORDER BY LASTNAME — 查詢不加 X 鎖，誤導排查方向。
• 新報告 List of Inactive SQL Statements 顯示持有者事務歷史：
  #1 SELECT ... (查詢)
  #2 UPDATE EMPLOYEE SET SALARY = SALARY * 1.02 ← 真兇：全表更新加持 X 鎖未提交

啟用與調優指南

1. 基礎開關：DB2_CAPTURE_LOCKTIMEOUT=ON (實例級，動態生效) — 開啟基礎報告，開銷極低。
2. 進階歷史：CREATE EVENT MONITOR ... FOR DEADLOCKS WITH DETAILS HISTORY — 記錄完整事務 SQL 歷史，顯著增加監視器堆佔用，僅在疑難案例臨時啟用。
3. 文件管理：報告寫入 DIAGPATH，DB2 不自動清理，DBA 需定期歸檔/刪除，防止文件系統爆滿。

已知局限 (官方文檔)

• 靜態 SQL (包綁定) 語句文本可能不顯示，需結合包名/節號查 SYSCAT.STATEMENTS。
• DB2 內部系統鎖 (目錄鎖、工具鎖) 不生成用戶級報告。
• 極高並發下報告生成可能延遲或丟失，建議配合 db2pdcfg -catch locktimeout 獲取堆棧。

最佳實踐檢查清單

1. 常態：DB2_CAPTURE_LOCKTIMEOUT=ON 常開。
2. 發生超時：優先分析 DIAGPATH/*.locktimeout 文件，定位請求者/持有者/鎖資源/關鍵 SQL。
3. 疑難雜癥：臨時啟用 DETAILS HISTORY 事件監視器，復現後即關閉。
4. 持有者 SQL 歷史中尋找 未提交的 DDL/DML (UPDATE/DELETE/ALTER/LOCK TABLE) — 90% 以上是真因。
5. 優化方向：縮短事務、調整隔離級、增加索引避免掃描鎖升級、應用層重試邏輯。

總結

DB2 9.5 的鎖超時報告 + 語句歷史功能，將鎖爭用排查從「盲人摸象」推進到「全景可視」。核心價值在於還原持有者的完整事務上下文，讓 DBA 能精準定位「那條早已執行完的 UPDATE」—— 這正是解鎖生產環境疑難鎖超時的金鑰匙。