深入解析 DB2 通用資料庫的並發控制機制

並發控制的核心價值

在資料庫管理系統（DBMS）領域中，「並發性」指的是多個應用程式能夠近乎同時存取相同資料的能力。由於資料共享是 DBMS 的核心優勢之一，系統必須提供有效機制來管理並發存取，確保資料的一致性與完整性不受損害。

為何單純串列處理不可行？

最直觀的做法是採用「僅串列」模式：每筆交易必須等待前一筆完成。但在現今的線上系統與高併發場景下，這種方式造成的效能瓶頸完全無法接受。

鎖機制：並發控制的基石

DB2 採用鎖機制來協調多應用程式對資料的存取。鎖是一種軟體控制機制，在維護資料完整性的前提下，最大化資料存取的並發度與吞吐量。DB2 UDB 與 IRLM（內部資源鎖管理器）協同管理鎖，追蹤鎖的持有者與請求者，判斷資源是否可用。

三大並發異常情境

若缺乏有效的並發控制，將面臨以下風險：

• 遺失更新：兩應用程式同時讀取同一行並計算新值，後寫入者覆蓋先前更新。
• 不可重複讀：同一交易中兩次讀取同一行，中間被其他交易修改，導致結果不一致。
• 存取未認可資料：應用程式讀取了另一交易尚未提交（或已回滾）的資料，據此進行後續處理造成錯誤。

鎖模式與粒度

DB2 主要支援兩種基本鎖模式：

• 共享鎖（S鎖）：關聯唯讀操作，允許多交易同時讀取同一資源。
• 排他鎖（X鎖）：關聯寫入操作，持有者可更新資料，其他交易在鎖釋放前無法存取該資源。

為平衡並發度與系統開銷，DB2 提供多層級鎖粒度，範圍從單一列、資料頁、表格到整個表空間。應用程式若需大範圍存取可用粗粒度鎖，精細操作則用細粒度鎖，避免不必要的等待或過多鎖管理開銷。

鎖等待、超時與死結

• 鎖等待：請求的鎖被他人持有且不相容時，請求者進入暫掛狀態，按 FIFO 排隊。
• 超時：等待超過預設閾值（LOCKTIMEOUT），交易被終止並回滾。
• 死結：兩或多交易互相持有對方所需資源的鎖，形成循環等待。DB2 會定期檢測（DLCHKTIME），選擇代價最小的交易犧牲以打破僵局。

實用程式與命令的並發機制

SQL 應用程式使用交易鎖，而 DB2 實用程式（如備份、重組）則透過聲明與放棄機制配合相容性規則來協調存取。聲明宣告正在存取某對象；放寒則阻止新聲明並等待現有聲明釋放，實現實用程式與線上交易的並共存。

資料庫設計層面的並發優化

分區表策略

建議大型表採用分區表空間，依分區索引鍵值範圍劃分。每個分區為獨立資料集，可獨立管理。批次作業可拆分至不同分區並行執行，大幅縮短佔用時間；實用程式也可針對特定分區操作，不影響其他分區存取。

鎖升級機制

當單一交易在表/表空間上持有大量細粒度鎖（頁/列/LOB）時，DB2 會自動升級為表/表空間/分區級鎖，並釋放底層鎖。若啟用分區鎖定（LOCKPART YES），升級僅影響被鎖定分區，未鎖定分區保持可用。升級觸發點由 LOCKSIZE 與 LOCKMAX 參數決定。

LOCKSIZE 選擇指引

• ANY（預設）：DB2 自動選擇，非 LOB 表通常用 PAGE，LOB 表用 TABLESPACE。
• ROW（列鎖）：V4 版引入。適合頁面鎖競爭激烈、隨機存取模式的場景，但會增加鎖管理開銷；若多交易以不同順序更新同頁同列，反而可能增加死結風險。

決策建議：以效能監控數據為依據，在鎖開銷與並發收益間權衡。預設值適用大多數情境，僅在明確發現頁面鎖熱點時考慮列鎖。