DB2 資料庫設計與效能調優核心原則

前言

本文整合多方資源，針對 z/OS 環境下的 DB2 通用資料庫（UDB）效能議題，提供給 IBM 商業夥伴與客戶的設計指導。重點著墨於資料庫設計層面，涵蓋邏輯與物理設計、表空間選擇、索引策略、分區技術、資料壓縮等關鍵領域，旨在協助在特定環境中達到最佳效能。

效能管理方法論

介入時機

效能考量應在應用程式與資料庫設計的初始階段即納入。早期評估資源需求，能避免後期修改帶來的高成本與困難。

關注焦點

集中精力於核心業務負載、關鍵響應時間需求、複雜邏輯/資料存取、大量資料存取、高資源消耗、直接面向客戶的交易應用。

資料庫設計階段

邏輯設計 vs 物理設計

邏輯模型是需求的規範表達，不考慮實體儲存；物理設計則轉化為具體架構，需考量存取需求與效能細節，核心在於表設計與索引設計。

主動管理策略

• 早期識別效能因素，建立效能基線（SLA）。
• 持續監控系統與應用，預防問題發生。
• 避免等到專案末期才關注效能。

核心設計考量

表空間類型選擇

• 簡單表空間：多表共用頁面，不建議用於生產環境。
• 分段表空間：多表，各表佔用獨立段，掃描效率高，支援大量刪除/截斷後即時釋放空間。
• 分區表空間：單表，依索引鍵值範圍分區，支援並行處理（查詢、CP、Sysplex）、部分資料操作、熱點資料隔離。大表首選，小表若用於大表連接也可考慮。
• LOB 表空間：專存 BLOB/CLOB/DBCLOB。

記錄長度與頁面大小

• 固定長度記錄優於可變長度（避免行遷移、額外 I/O）。
• 預設 4KB 頁面適用於小行、隨機存取；行長超過 4KB 或單頁僅能容納極少行數時，需改用 8/16/32KB 頁面（由緩衝池頁面大小決定）。
• DB2 V8 允許動態調整欄位大小，減少對可變長度記錄的依賴。

非正規化策略

邏輯模型追求正確性與無冗餘，但物理實現常需為效能妥協。非正規化（複製常用欄位以減少連接）可提升效能，但必須完整文檔化變更理由與細節，謹慎評估維護成本。

大表設計：分區與索引

大表設計的兩大關鍵：實施分區與建立有效索引。分區表空間提供並行性、資料隔離、可用性提升；分區索引鍵值範圍需與連接謂詞對齊（同分區數、同邊界值）。

資料壓縮

• 透過 COMPRESS YES + LOAD/REORG 啟用，以字典替換重複字串。
• 權衡：CPU 成本（壓縮/解壓） vs I/O 減少、緩衝池利用率提升。硬體加速可大幅降低 CPU 開銷。
• 適用性：大表、重複模式多、行長不接近頁面大小者效果最佳。可用 DSN1COMP 預估效果。
• 建議：生產環境中對受益表空間/分區啟用壓縮，效能優勢通常超過 CPU 成本。

大量資料載入優化

• 手動建立多個 LOAD 作業（每分區一個）或單一作業載入多個分區，利用 I/O 子系統並行。
• 指定 SORTKEYS 參數：將索引鍵傳給記憶體排序器，避免寫入/讀取排序工作檔，並實現載入與排序交疊。

工作負載特徵與 GETPAGE

• 交易型：SQL 簡單、量大、需極低響應時間、緩衝池命中率高。
• 查詢/決策支援：SQL 複雜、量較輕、容忍分鐘至小時響應、常掃描全表與排序。
• 批次/工具程式：大量序列處理、需在窗口內完成、頻繁 COMMIT、資源消耗大。

磁碟 I/O 是響應時間最大因素，GETPAGE 次數 是反映 DB2 整體工作量的最佳指標。

經驗法則（ROT）的正確態度

ROT 來源於經驗簡化，僅供粗略估計，不可作為精準依據。必須在自身環境中驗證、調整，並隨硬體、軟體、DB2 版本演進而更新。IBM Redbooks 是良好的 ROT 參考資源。

結語

資料庫設計效能優化是系統生命週期的持續任務。掌握核心原則、結合實際負載特徵、善用 DB2 進階特性（分區、壓縮、並行），方能構建高效能的 DB2 系統。