DB2 鎖等待實戰分析：從症狀到根因的完整排查流程

鎖等待：DB2 開發與運維的常見痛點

DB2 擁有豐富的鎖模式 (S, IS, NS, X, IX, SIX, NX, U, Z...) 雖保障資料一致性，但也帶來複雜的鎖等待問題。許多開發人員面對「簡單查詢卻長時間無回應」時不知所措。本文提供一套標準化排查流程，助你快速定位鎖爭用根因。

重現場景：一個經典的鎖等待案例

環境準備

-- 建立測試表
db2 "create table test_lock (col int, col2 char(10))"

開啟三個命令視窗模擬並發場景：

• 視窗 1 (持有鎖的交易)： db2 +c "insert into test_lock values(1,'aaa')" (未提交)
• 視窗 2 (被阻塞的查詢)： db2 "select * from test_lock" → 長時間掛起
• 視窗 3 (DBA 排查視窗)： 執行診斷指令

第一步：確認鎖等待存在 — LIST APPLICATIONS

db2 list applications show detail

關鍵輸出解讀：

XUXIAOF db2bp.exe 22 ... UOW 正在等待 ...  (視窗1，持有鎖)
XUXIAOF db2bp.exe 68 ... 鎖定等待 ...      (視窗2，等待鎖)

出現 鎖定等待 (Lock-waiting) 狀態即確認存在阻塞。記錄應用程式代理碼 (Application Handle)，如範例中的 68。

第二步：深入鎖細節 — db2pd -locks

db2pd -d sample -locks show detail

重點關注 Sts (狀態) = W (Waiting) 的記錄：

Address    TranHdl Lockname                Type Mode Sts Owner Dur HoldCount ...
0x7F8911B0 8       03000500040080020000000052 Row  .NS  W   2     1   0 ...
TbspaceID 3 TableID 5 PartitionID 0 Page 640 Slot 4

• Lockname：編碼的鎖資源識別碼，可解析出表空間、表、頁碼、槽位
• Mode .NS：等待模式 (Next Key Share)，預期相容性衝突
• Owner：持有鎖的應用程式代理碼 (此處為 2，對應視窗 1)

第三步：關聯 SQL 與業務邏輯

結合 db2pd -d sample -applications 或 MON_GET_ACTIVITY 取得等待應用正在執行的 SQL 文本，以及持有鎖應用的未提交交易內容，即可釐清業務衝突點。

常見解決策略

• 縮短交易範圍：盡早 COMMIT/ROLLBACK，減少鎖持有時間
• 調整隔離級別：評估是否可使用 CS (Cursor Stability) 或 UR (Uncommitted Read) 降低鎖強度
• 索引優化：確保查詢走索引掃描而非表掃描，減少掃描行數與鎖獲取量
• 應用層重試邏輯：針對死鎖 (-911) 或鎖逾時 (-913) 實作指數退避重試

進階工具提示

DB2 9.7+ 提供 MON_GET_LOCKS、MON_LOCKWAIT 表函數，配合 db2cos (Call Stack) 可獲取更豐富的堆疊資訊，建議納入常態監控儀表板。

掌握「列應用 → 看鎖細節 → 關聯 SQL」三步曲，讓鎖等待問題無所遁形，是 DB2 DBA 與開發人員的必備核心技能。