為什麼需要鎖？
DBMS 與檔案系統的本質差異在於交易支援。LOG 保證持久性，而 LOCK 則確保交易序列化，解決並發存取帶來的資源競爭。DB2 採用 LOCK、LATCH、CLAIM/DRAIN 三大機制實現序列化，並定義四種隔離等級應對不同業務場景。
並發異常的四大現象
- 遺失更新：兩筆交易讀取同一資料並嘗試更新，後寫入者覆蓋先前更新。
- 髒讀：讀取尚未提交的資料，若前一交易回滾，資料實際從未存在。
- 不可重複讀：同一查詢在交易中多次執行，因他交易修改/刪除而得到不同結果。
- 幻影讀：依條件查詢時，他交易插入符合條件的新列，導致重新查詢結果集變化。
鎖的核心屬性
| 屬性 | 說明 |
|---|
| OBJECT | 鎖定對象：TABLESPACE、TABLE、PAGE、ROW 等 |
| SIZE | 粒度：ROW < PAGE < TABLE < TABLESPACE，影響並發度與資源消耗 |
| MODE | 相容性：S（共享）、U（更新）、X（排他） |
| DURATION | 持有時間：COMMIT 釋放或 WITH HOLD 跨交易保持 |
| PARTICIPANTS | 持有者：TRANSACTION 或 DB2 MEMBER |
意圖鎖與層級鎖定
為解決粒度衝突，DB2 採用意圖鎖：上層取 IS/IX，下層取 S/X。無論 LOCKSIZE 為何，DB2 總先取得 TABLESPACE 級鎖，再向下鑽取細粒度鎖。
CLAIM / DRAIN：工具與 SQL 的協調
- SQL 之間用 LOCK 協調
- UTILITY 與 SQL 之間用 CLAIM/DRAIN：DRAIN 阻擋新 CLAIM，等待現有 CLAIM 釋放
- UR（Uncommitted Read）雖不取鎖，但會增加 CLAIM 計數
- WITH HOLD 游標在 COMMIT 時不減少 CLAIM
LATCH：輕量級序列化
由 DB2 或 IRLM 管理，用於緩衝池頁面、內部資料結構保護，不涉及死鎖偵測，效能較高。
資料共享環境的進階鎖機制
P-LOCK（實體鎖）
- 僅存在於 Data Sharing，Owner 為 DB2 MEMBER
- 維護緩衝池一致性（GBP）、頁面集狀態協商
- 可在成員間協商降級（如 X→SIX），避免全域衝突
- 無 Timeout/Deadlock 偵測
L-LOCK（邏輯鎖）與層級傳播
- Parent Lock（TABLESPACE/PARTITION）幾乎總是傳播到 CF
- Child Lock（PAGE/ROW）僅在跨系統讀寫衝突時傳播
- V8 起引入「基於 Pageset P-lock 狀態的非同步子鎖傳播」，大幅減少 CF 往返
CF LOCK 結構：MRL 與 LOCK TABLE
- MRL (Modified Resource List)：記錄所有修改鎖，失效時保留 Retained Lock
- LOCK TABLE：雜湊指標池，用於全域鎖衝突偵測，過小會產生 FALSE CONTENTION
- XES (Cross-system Extended Services) 僅理解 S/X 兩種鎖，DB2 內部多樣鎖型需映射，V8 Protocol Level 2 優化映射邏輯，顯著降低 XES CONTENTION
常見鎖問題與診斷工具
| 問題類型 | 徵兆訊息 | IFCID |
|---|
| TIMEOUT | DSNT376I | 196 |
| DEADLOCK | DSNT375I | 172 |
| LOCK ESCALATION | DSNI031I | 337 |
| LONG SUSPENSION | — | — |
| EXCESSIVE LOCKS | — | — |
診斷工具箱
-DISPLAY DATABASE ... LOCKS/CLAIMERS（不顯示頁/列鎖）-DISPLAY THREAD TYPE(*) LIMIT(*)- EXPLAIN：PLAN_TABLE 的 TSLOCKMODE 欄
- TRACE：IFCID 172/196/337/313，Locking、Latch、GBP 區段
鎖結構空間不足應對
- 檢查是否有 DOWN 狀態的 DB2 持有 Retained Lock
- RESTART 失效 DB2 回收 Lock List 空間
- 降低 LOCK ESCALATION 門檻
- 動態擴充 CF Lock Structure：
SETXCF START,ALTER,STRNAME=...,SIZE=newsize 或重建
掌握 DB2 鎖機制全貌，從單一子系統到 Data Sharing 叢集，配合監控與參數調校，才能在高併發環境下穩住效能底線。
