DB2 for z/OS Web 應用死鎖根因分析：從鎖跟蹤到 SQL 定位的完整實戰流程

背景與目標

複雜 Web 環境下，DB2 for z/OS 出現死鎖，需快速定位導致死鎖的不良 SQL。本文演示如何配置 DB2 Performance Monitor (DB2PM) 採集 Locking 跟蹤 與 SQL Activity 跟蹤，並聯鎖分析與 SQL 關聯分析鎖定問題語句。

跟蹤配置雙軌並行

軌道 A：Locking 跟蹤（捕獲死鎖詳情）

1. Collect Task A → Trigger: Immediate Start
2. 選項：Locking, Data Type, IFCID, Requesting Location, Plan name, Authid
3. Data Type: Lockout
4. IFCID 選擇：105 (DBID/OBID 轉換)、107 (資料集開關)、172 (Deadlock)
5. Trace Qualification：填 DB 用戶/模式（例：TUSER03/TGUSER03）
6. 輸出數據集：TGUSER03.DB2PM.TRACE01

軌道 B：SQL Activity 跟蹤（捕獲語句執行軌跡）

1. Collect Task B → Trigger: Immediate Start
2. 選項：SQL Activity, 全數據類型
3. IFCID 選擇（關鍵 18 項）：16,20,53,58,59,60,61,63,64,65,66,68,69,70,71,88,89,105
4. Trace Qualification：同軌道 A
5. 輸出數據集：TGUSER03.DB2PM.TRACE02

死鎖原理速覽

Web 應用常見頁鎖/行鎖（S/U/X 三模式）。死鎖經典模型：

JobOne 持有 表M 頁B X鎖 → 請求 表N 頁A X鎖 (被 JobTwo 持有) → 掛起
JobTwo 持有 表N 頁A X鎖 → 請求 表M 頁B X鎖 (被 JobOne 持有) → 掛起
→ 循環等待 → 死鎖 → DB2 選擇 Victim 回滾

實戰分析：雙跟蹤聯鎖定位

步驟 1：分析 Locking 死鎖報告

報告關鍵欄位：

• WAITERS=2：兩個等待者（LUW 實例 0CC544053119、0E26A4053107）
• 資源對立：
  實例 A 持有 SW03DB1.USERS.X'00004E'.X'2B' X鎖 → 請求同表 X'00004C' S鎖
  實例 B 持有 SW03DB1.USERS.X'00004C'.X'2B' X鎖 → 請求同表 X'00004E' S鎖
• 死鎖時間：06:30:09.41044991
• BLOCKER is HOLDER --*VICTIM*：標識被選為犧牲者的線程

步驟 2：關聯 SQL Activity 找語句

對每個 LUW 實例：

1. 在 SQL 跟蹤中找到死鎖前 最近一次 COMMIT 時間
2. 篩選該 COMMIT 後至死鎖時間窗口內、訪問同一資源 (SW03DB1.USERS) 的 SQL

-- 實例 0CC544053119
最新 COMMIT: 06:28:51.04
窗口: 06:28:51.04 ~ 06:30:09.41
發現: INSERT INTO USERS ... ; SELECT FROM USERS ... (無中間 COMMIT)

-- 實例 0E26A4053107
最新 COMMIT: 06:28:50.65
窗口: 06:28:50.65 ~ 06:30:09.41
發現: SELECT FROM USERS ... ; INSERT INTO USERS ... (無中間 COMMIT)

步驟 3：根因結論

兩線程交叉執行 INSERT 與 SELECT，且 缺乏中間提交，導致表掃描鎖升級衝突，並發執行時形成死鎖。

優化建議

• 縮短事務：在邏輯允許處增加 COMMIT，減少鎖持有時間
• 索引優化：為 USERS 關鍵查詢欄位建立索引，避免表掃描
• 隔離級別：讀密集操作考慮 CS 或 UR，減少 S 鎖請求
• 應用邏輯：避免長事務中交叉讀寫同一熱點表

方法論總結

1. 啟用雙跟蹤（Locking + SQL Activity）同步採集
2. 以死鎖時間與 LUW 實例為鍵，回溯 SQL Activity 最近 COMMIT 窗口
3. 聚焦訪問衝突資源的 SQL，識別長事務、缺索引、交叉讀寫模式
4. 針對性優化：提交頻率、索引、隔離級別、應用邏輯重構

此法讓開發與測試人員均能獨立完成「死鎖 → 壞 SQL → 優化」閉環，大幅縮短並發性能問題解決週期。