深入解析 DB2 鎖機制：相容性、升級、死鎖與超時處理

DB2 鎖相容性核心概念

在 DB2 資料庫中，鎖是確保資料一致性與並發控制的關鍵機制。當一個交易持有資源鎖時，另一個交易請求同一資源的鎖，DB2 會檢查兩者的相容性。若相容，第二個交易即可獲取鎖；若不相容，則必須等待第一個交易釋放鎖。這種機制直接影響系統的並發效能。

鎖相容性矩陣定義了各種鎖模式（如共享鎖 S、排他鎖 X、更新鎖 U 等）之間的共存規則。詳細的相容性對照表請參考 IBM 官方文件《DB2 Universal Database Administration Guide: Performance》或資訊中心的 "Lock type compatibility" 主題。

鎖升級：從行級到表級的自動轉換

為了控制鎖佔用的記憶體空間，DB2 透過 maxlocks 參數限制鎖清單大小。當單一交易持有的鎖數量超過閾值，系統會自動觸發鎖升級，將該交易在同一資料表上的多個行級鎖轉換為單一表級鎖，釋放記憶體空間。

升級運作流程

1. 偵測到鎖空間不足時，選定該交易相關的一個資料表。
2. 為該表申請表級鎖，並釋放該表所有行級鎖。
3. 若空間仍不足，重複上述步驟處理其他表，直到釋放足夠空間。
4. 若所有行級鎖皆已升級仍不足，交易將收到 SQL 錯誤碼，被迫提交或回滾並終止。

鎖升級雖能解決記憶體壓力，但會降低該表的並發存取能力，需在設計時權衡。

死鎖：循環等待的困境與解決

死鎖發生於兩個或多個交易互相持有對方所需資源的鎖，形成循環等待。例如：

• 交易 1 持有表 A 的 X 鎖，請求表 B 的 X 鎖。
• 交易 2 持有表 B 的 X 鎖，請求表 A 的 X 鎖。

兩者皆無法推進，若無外部介入將無限期等待。DB2 部署死鎖偵測器（非同步背景程序）定期掃描鎖子系統，一旦發現死鎖，會選擇一個犧牲者交易終止並回滾，釋放其鎖讓其他交易繼續。被終止的交易會收到 SQL 錯誤碼（如 SQL0911N）。

鎖超時：防止無限期等待的安全網

為避免交易因鎖不可用而長時間阻塞，可透過 locktimeout 資料庫配置參數設定等待上限（秒）。超時後，等待交易會收到錯誤（SQL0911N reason code 68）並自動回滾。這在分散式交易環境中尤為重要，能有效防止應用程式因網路或邏輯問題導致的連鎖阻塞。

最佳實務建議： 根據業務容忍度設定合理的 locktimeout（預設 -1 代表無限等待），並監控死鎖與超時事件，優化 SQL 與索引以減少鎖爭用。