SQL911 RC=68 Lock Timeout 深度剖析：從鎖鏈追蹤到 32/64 位遷移陷阱

現象與挑戰

客戶系統（DB2 8.2 FP10）頻發 SQL911 RC=68（Lock Timeout），應用強制退出。Lock Timeout 與 Deadlock 不同，**事件監控器無法捕捉**，只能靠設定 LOCKTIMEOUT=60 秒，編寫腳本每 10 秒輪詢 Snapshot 捕捉現場。

監控腳本核心邏輯

while [ 1 -eq 1 ]; do
  wc=$(db2 "list applications show detail" | grep -i "Lock-Wait" | wc -l)
  if [ $wc -gt 0 ]; then
    db2pd -db dwbllog -locks showlocks > 58121.locks
    db2pd -db dwbllog -transactions > 58121.trans
    db2pd -db dwbllog -agents > 58121.agents
    db2pd -db dwbllog -applications > 58121.app
    db2 "get snapshot for locks on dwbllog global" > 58121.locksnap
    db2 "get snapshot for applications on dwbllog global" > 58121.appsnap
    db2pd -db dwbllog -locks showlocks > 58121.locks.2
    print "Done snapshots"
  fi
  sleep 10
done

現場還原：兩階段鎖鏈分析

受害者 Application Handle 66681

Application status = Lock-wait
ID of agent holding lock = 65836
Lock name = 0x53595353483230320619C45A41
Lock object type = Internal Plan Lock
Lock mode = Exclusive Lock (X)
Lock mode requested = Share Lock (S)
Lock wait start timestamp = 04/19/2006 09:54:40.879549

關鍵發現：**S 鎖等待 X 鎖**，鎖類型為 Internal Plan Lock（套件鎖）。

持鎖者 Application Handle 65836

db2pd -locks 顯示該應用持有多把 Internal Plan Lock 的 X 鎖，其中關鍵一把：

Lock Name = 0x53595353483230320619C45A41
Object Type = Internal Plan Lock
Mode = X
Pkg UniqueID = 53595353 48323032  (ASCII: SYSSH202)

根因定位：套件重綁定衝突

根據 IBM 文檔，套件鎖在以下操作會以 X 模式持有：

1. BIND/REBIND 套件
2. DROP 套件
3. INVALIDATE 套件
4. INOPERATE 套件

查詢目錄確認：

select pkgname, last_bind_time from syscat.packages where pkgname='SYSSH202';
-- 結果顯示 NULLID schema 下 SYSSH202 最近綁定時間為 2006-04-19-10.17.53，緊貼故障時間

客戶確認：**近期完成 32-bit → 64-bit 遷移**，但未重新綁定系統套件。

解決方案與驗證

db2 bind @db2ubind.lst
db2 bind @db2cli.lst

重綁系統內建套件後，Lock Timeout 徹底消失。

深度補充：為什麼 32/64 位遷移會觸發此問題？

• 遷移後，現有應用仍載入舊 32-bit 套件快取；新 64-bit 進程嘗試 REBIND/INVALIDATE 同名套件時需獲取 X 鎖
• 大量並發應用持有該套件的 S 鎖（正常執行），導致 REBIND 進程長時間等待 → 超時連鎖
• SYSSH202 為 DB2 內建靜態 SQL 套件，極高熱度，放大衝突

備選方案（不推薦常規使用）

DB2_NO_PKG_LOCK=ON 可關閉套件鎖，但副作用嚴重：

• 套件失效/重綁期間可能出現 SQL 錯誤或錯誤執行計劃
• 失去套件級並發控制保護
• 僅作為緊急臨時繞過，必須在維護窗口完成標準重綁後關閉

最佳實踐檢查清單

• ✅ 任何位元寬度遷移、Fixpack 升級、資料庫升級後，**務必執行 db2rbind 或手動 bind @db2ubind.lst @db2cli.lst**
• ✅ 監控腳本常態化部署：db2pd -locks showlocks 可快速定位 Internal Plan Lock 持有者
• ✅ 設定 LOCKTIMEOUT 非 -1（建議 30~60 秒），避免永久等待佔用代理
• ✅ 定期檢視 SYSCAT.PACKAGES.LAST_BIND_TIME 異常值

總結

本案例展示了從 SQL911 RC=68 現象，透過 db2pd 多維度鎖快照、套件目錄交叉比對，精準定位至「32/64 位遷移後系統套件未重綁導致套件鎖 X/S 衝突」。核心教訓：**環境變更後的套件重綁是不可省略的強制動作**，而非可選優化。