DB2 最佳實踐精華：基礎設計、效能調優與營運管理性全方位指南

前言：為什麼需要最佳實踐清單？

DB2 for Linux, UNIX, and Windows 提供強健的關係與 XML 資料平台，但「能跑」與「跑得好、好維護」中間隔著無數細節。本文蒐羅官方紅皮書、developerWorks 專區、IBM Press 經典著作與實戰經驗，提煉出可直接落地的最佳實踐清單，涵蓋遷移、設計、配置、SQL、JDBC、索引、日誌、並發、維運八大面向。

一、資訊獲取：建立你的知識庫

• developerWorks IM 專區：文章、教程、試用版、技術庫
• IBM Press 經典：《Understand DB2: Learning Visually with Examples》(第 2 版對應 V9.5)，《DB2 V8 Handbook》，《IBM DB2 Version 9 New Features》
• IBM Redbooks：深度技術指南
• Virtual Innovation Center (VIC)：合作夥伴專屬課程教材

二、遷移利器：DB2 Migration Toolkit (MTK)

• 支援來源：SQL Server、Oracle、Sybase、MySQL
• 可遷移：表、視圖、索引、RI 約束、UDF、預存程序
• 關鍵數據類型原則：
  1. 應用變數/JDBC set 方法與 DB2 欄位類型嚴格匹配 — 消除隱式轉換與錯誤
  2. 採用滿足需求的最小類型 (如 SMALLINT 替代 INTEGER)
  3. MTK 產生的 DECIMAL(x,0) 應評估改為 INTEGER/BIGINT — 但需考慮運算結果類型

三、資料庫配置：從 AUTOCONFIGURE 起步

1. 起手式：AUTOCONFIGURE 或 Configuration Advisor — 依工作負載特性給出基準值
2. 能自動就自動：多參數支援 AUTOMATIC，讓 DB2 依運行時資源動態調整
3. 必調關鍵參數：
   • 頁面大小：預設 4K，最小建立 32K Bufferpool + 32K 系統臨時表空間 + 32K 用戶表空間，支援 >4K 行
   • Bufferpool：預設極小，生產環境大幅加大；DB2 9 可交由 STMM (Self-Tuning Memory Manager) 全自動
   • 鎖列表：V8 預設 100 (4K pages) 極易升級鎖導致死鎖，至少調 1000；V9 設 AUTOMATIC 由 STMM 管控

四、SQL 寫碼鐵律：選、更、增效率

• APPEND ON：不需物理聚簇時開啟，大幅加速 INSERT (DELETE/UPDATE 空間重用需 REORG 後生效)
• 禁用 SELECT *：減少網路/IO、避免 Schema 變更衝擊應用
• 頻繁更新欄位集中放置 — 減少日誌記錄量 (微優化，勿大動架構)
• 善用 SQL 預存程序：減少網路往返、啟用靜態 SQL 預編譯優化、封裝可重用業務邏輯組件、單一職責原則

五、並發最大化與死鎖最小化

Registry Variables (開發早期啟用、全測試驗證)

DB2_EVALUNCOMMITTED=YES        (V8 建議 YES_DEFERISCANFETCH)
DB2_SKIPDELETED=ON
DB2_SKIPINSERTED=ON

隔離級別：選業務可接受的最低級別 (CS > RS > RR)

監控鎖升級：Bufferpool/DB2DIAG/Windows Event/STMM 任一管道，確保 LOCKLIST/MAXLOCKS 足夠

唯讀/單連接表可 ALTER TABLE ... LOCKSIZE TABLE 減少鎖開銷 (謹慎使用)

死鎖預防三板斧

1. 全應用統一資源訪問順序 (如 A→B→C)
2. V8 必調大 LOCKLIST；V9 靠 STMM
3. RI 依賴表必建外鍵匹配索引

六、連接池：標配與進階

• 應用服務器管理池 > 應用自管池 — 消除開關連開銷
• 大量連接場景啟用 Connection Concentrator：少量後端連接服務大量前端請求，省記憶體

七、動態 vs 靜態 SQL：理性選擇

• 動態 SQL 普及、易開發、語句緩存重用效能逼近靜態
• 靜態 SQL 仍有優勢：安全性管控、極致 OLTP 效能、SQLJ/CLI Static Profiling 專用場景

八、PREPARE 成本最小化

• 參數標記 (Parameter Markers) 一次定義多次重用
• 高成本語句可用字面值替換參數標記助優化器 — 但會膨脹語句緩存
• 靜態 SQL 包用 REOPT ALWAYS 綁定；動態 SQL 用全域/語句級優化配置指定 REOPT ALWAYS

九、JDBC 高效用法

1. 精確對應 setXXX 方法與欄位類型 — 避免轉換開銷與類型錯誤
2. 避免可捲動結果集 — 服務端建臨時表支撐，大結果集殺手

十、索引策略：Design Advisor 雙軌制

1. 開發階段：核心 SQL 輸入 Design Advisor 產出候選索引
2. 測試階段：實際 Workload 填充動態 SQL 緩存後再跑 Design Advisor — 依執行頻率權衡
3. 前置條件：必先 RUNSTATS
4. 進階：SET CURRENT EXPLAIN MODE RECOMMEND INDEXES → 執行 SQL 填充 ADVISE_INDEX → EVALUATE INDEXES → db2exfmt 對比實/虛索引計劃

十一、日誌效能：寫入速度決定寫入極限

• 關閉 Autocommit (JDBC 預設開) — 每提交一同步日誌；若業務需逐句提交則保留
• 非必要不記大物件 (CLOB/BLOB/DBCLOB)
• 日誌專盤：隔離於表空間/資料檔，配快速寫入緩存控制器
• 日誌緩衝區 ≥ 256 頁

十二、訪問計劃驅動 SQL 調優

• Visual Explain (Control Center)：最直觀入門
• db2expln：直接餵 SQL、分析包內靜態 SQL 方便
• db2exfmt：需先 EXPLAIN 填表，資訊最全，適合深度分析

十三、運行時與可管理性鐵律

結語

最佳實踐非銀彈，而是經驗結晶的檢核清單。逐項落地、持續度量、按場景取捨，方能打造「有效、高效、好維護」的 DB2 實作。