DB2 數據庫效能調校：揭開 20 大常見迷思與誤區

前言

在 DB2 數據庫的管理與優化領域，流傳著許多「經驗之談」，但其中不少其實是會誤導 DBA 與開發人員的迷思。本文整理自實務經驗，盤點 20 個關於 DB2 效能理解的常見錯誤認知，並針對每一點給出實際情況的釐清，幫助您避開陷阱，打造高效能的資料庫環境。

迷思 1：邏輯設計必須與物理設計完全對應

實情： 物理設計應盡量貼近邏輯結構，但為了效能所做的物理調整（如分區、索引、叢集等）往往超越邏輯設計範疇，不可忽視。

迷思 2：將所有物件放入單一緩衝池 (BP0) 讓 DB2 自行管理

實情： 僅在記憶體極度受限（< 10,000 個 4K 頁）且無暇管理時才建議如此。最佳實務是：除 DB2 目錄與 Catalog 外，勿將其他物件置於 BP0。

迷思 3：DSNDB07 (工作資料庫) 100% 為循序存取

實情： 因工作檔涉及頁面隨機存取，隨機 I/O 佔比可達 45%，通常落在 3%~10% 區間。

迷思 4：VARCHAR 欄位應永遠置於列末尾

實情： 唯有「頻繁讀取、極少更新」的表格才適合；若頻繁更新，置於末尾反而最差，甚至壓縮表也同理。

迷思 5：程式碼應遵循邏輯流程編寫

實情： 偽碼與流程圖不顧慮 DB2 效能。在 OLTP 交易中，為效能而偏離邏輯順序（如提前過濾、避免鎖升級）極為常見。

迷思 6：大多數業務邏輯不在 SQL 中處理

實情： 事實相反，SQL 是豐富的集合運算語言。最大困境在於開發者常將 SQL 當成 I/O 處理器，而非集合處理器。

迷思 7：代碼表與參考表應搭配 DB2 宣告式 RI (Referential Integrity) 使用

實情： RI 不應作為「輸入驗證捷徑」，僅適用於真正的父子關聯關係。

迷思 8：一張表至多只需一兩個索引

實情： 索引數量應依查詢效能需求決定，而非人為設限。

迷思 9：非分割索引 (NPI) 不應使用，特別是大表

實情： NPI 雖帶來管理挑戰，但為提供正確存取路徑與效能，往往不可或缺。

迷思 10：大表必須分割

實情： 「資料量大即效能差」是過往遺留觀念。現代 DB2 處理超過 60 億列的非分割表已非難事。

迷思 11：DB2 預設值即最佳設定

實情： 預設值隨版本變動，鮮為最佳。例如 BIND 參數 CURRENTDATA 需視隔離等級與並發需求調整。

迷思 12：WHERE 條件禁用否定邏輯 (NOT、!=、<>)

實情： 僅當否定謂詞導致不必要的表空間掃描時才需避免；大多數情況下，交由 DB2 引擎過濾更佳。

迷思 13：僅靠 EXPLAIN 即可判斷存取路徑優劣

實情： EXPLAIN 不顯示查詢區塊執行順序、一/二階段謂詞、區塊執行耗時。需結合 Visual Explain 等工具與完整上下文綜合判讀。

迷思 14：EDM Pool 不宜過大以免分頁

實情： EDM Pool 透過分頁（擴展儲存）提升效能，反而過小會導致頻繁重建內部結構，拖垮效能。

迷思 15：Extent (擴展區) 大小不影響其他面向

實情： 雖 SAN/ESS 控制器緩衝降低了 Extent 影響，但管理額外檢查與處理仍存於系統中。

迷思 16：關聯分割 (Relation Partitioning) 在 DB2 不適用

實情： 此技術已在多系統驗證有效，尤其在 BI 與行銷系統中，單一程式常多次運用。

迷思 17：所有 Package 僅綁定至兩個 Plan：一批次、一線上

實情： 這是早期 Package 機制誤解，實務上有諸多理由需區分更細緻的 Plan 結構。

迷思 18：Uncommitted Read (UR) 是壞事

實情： UR 是強效能增強手段，適用範圍遠超一般認知（如唯讀報表、資料倉儲抽取）。

迷思 19：無 Timeout 與 Deadlock 即無鎖定問題

實情： 鎖等待時間才是關鍵指標。僅統計死鎖/逾時次數屬「事後反應」，監控鎖等待才是「事前預防」。

迷思 20：ESA 資料壓縮永遠有益

實情： 壓縮雖節省空間，但會增加 CPU 開銷。每張表皆須個別評估，不宜全域啟用或全域關閉。

結語

打破迷思，回歸實測與監控數據，才是 DB2 效能調校的正道。願這 20 點釐清能為您的資料庫優化之路提供導引。