DB2 9.5 鎖定逾時分析新紀元：DB2_CAPTURE_LOCKTIMEOUT 與死結事件監視器實戰

舊有痛點：db2pd + db2cos 組合雖強但門檻高

DB2 9.1 時代需手寫 db2cos 腳本包裝 db2pd、以 db2pdcfg 註冊鎖定逾時事件，分析時仍需人工關聯多段 db2pd 輸出，且若鎖持有者為多語句事務，往往無法精準定位致命 SQL。

DB2 9.5 一鍵啟用：DB2_CAPTURE_LOCKTIMEOUT

db2set DB2_CAPTURE_LOCKTIMEOUT=ON
db2stop
db2start

啟用後，每次鎖定逾時自動在 DIAGPATH 目錄產生報告 db2locktimeout.dbpartition.agentid.timestamp，內含四大區塊：

1. 基本資訊：日期、時間、實例、資料庫、分區。
2. Lock Information：鎖名稱、類型（Row/Table）、表空間 ID、Table ID、Row ID。
3. Lock Requestor（請求端）：Auth ID、Application Handle/ID/Name、Agent ID、請求鎖模式（如 ..U）、隔離級別、完整 SQL 文本。
4. Lock Owner/Representative（持有端）：同樣身分資訊、持有鎖模式（如 ..X）、當前事務已執行的非作用中 SQL 歷史清單（需啟用死結事件監視器）。

實戰複現：EMPLOYEE 表雙事務衝突

環境準備

db2sampl                                    # 建立 SAMPLE 資料庫
db2 "update db cfg for sample using locktimeout 10"  # 設 10 秒逾時

事務 1（持有 X 鎖）

db2 "connect to sample"
db2 +c "update employee set salary = salary * 1.02"
db2 +c "select lastname, firstnme, salary from employee order by lastname asc"
-- +c 關閉自動提交，X 鎖持有至 COMMIT/ROLLBACK

事務 2（請求 U 鎖，10 秒後逾時）

db2 "connect to sample"
db2 +c "update employee set bonus = salary * 0.1 where job = 'MANAGER'"

自動產生的鎖定逾時報告（節錄）

LOCK TIMEOUT REPORT
Date: 03/01/2008
Time: 07:34:31
Instance: DB2
Database: SAMPLE
Lock Information:
 Lock Name: 02000600040040010000000052
 Lock Type: Row
 Lock Specifics: Tablespace ID=2, Table ID=6, Row ID=x0400400100000000
Lock Requestor:
 System Auth ID: FECHNER
 Application Handle: [0-38]
 Application ID: *LOCAL.DB2.080103063343
 Application Name: db2bp.exe
 Requesting Agent ID: 5232
 Lock timeout Value: 10000 milliseconds
 Lock mode requested: ..U
 Statement: UPDATE EMPLOYEE SET BONUS = SALARY * 0.1 WHERE JOB = 'MANAGER'
Lock Owner (Representative):
 System Auth ID: FECHNER
 Application Handle: [0-33]
 Application ID: *LOCAL.DB2.080103063332
 Application Name: db2bp.exe
 Lock mode held: ..X
 List of Inactive SQL Statements from current UOW: Not available

進階：啟用死結事件監視器獲取 SQL 歷史

預設報告僅顯示請求端 SQL，持有端顯示 Not available。建立 DETAILS HISTORY 死結事件監視器即可記錄持有端事務內所有已執行 SQL：

db2 "create event monitor evmondeadlock for deadlocks with details history write to file '/tmp/evmon'"
db2 "set event monitor evmondeadlock state 1"

再次觸發逾時，報告新增區塊：

List of Inactive SQL Statements from current UOW:
 Entry: #1
 Statement: SELECT LASTNAME, FIRSTNME, SALARY FROM EMPLOYEE ORDER BY LASTNAME ASC
 Entry: #2
 Statement: UPDATE EMPLOYEE SET SALARY = SALARY * 1.02

由此精準鎖定 UPDATE ... SET SALARY = SALARY * 1.02 為持有 X 鎖的罪魁禍首，解決舊方法只能看到最後一條 SELECT 的盲點。

表空間 ID/Table ID 反查表名

select tabschema, tabname from syscat.tables
where tbspaceid = 2 and tableid = 6;

運維提醒

• DIAGPATH 清理：報告檔案不會自動刪除，需定期清理或移動避免填滿檔案系統。
• 監視器堆負擔：DETAILS HISTORY 會增加監視器堆使用量，建議平時僅開啟 DB2_CAPTURE_LOCKTIMEOUT=ON，必要時才啟用事件監視器。
• 已知限制：靜態 SQL、DB2 內部鎖定、極長事務可能仍難完整重現；詳細限制請參閱官方文件「Lock timeout reporting」章節。

結語

DB2 9.5 透過註冊變數一鍵啟用、自動產生結構化報告、結合死結事件監視器提供完整 SQL 歷史，將鎖定逾時分析從「專家級偵探工作」降級為「標準化運維流程」，大幅縮短 MTTR（平均修復時間）。