DB2 資料庫設計效能準則：z/OS 環境最佳實踐指南

前言

開發早期的設計決策對 DB2 應用程式與資料庫效能有巨大影響。本文為 z/OS 環境取得更好效能提供一般性指導與建議，面向 IBM 業務夥伴，整理多方資料盡可能有效表述。不追求全面覆蓋或深度細節，旨在成為處理特定安裝環境資料庫效能問題的良好起點。

範圍聚焦資料庫設計效能。DB2 效能遠不止於此，受程式編碼邏輯、實際 SQL（應用程式設計）、安裝選項、緩衝池大小、調度優先級（系統效能）等影響。類別界線有時模糊：緩衝池大小/數量通常屬系統效能，但將特定表空間/索引指派給緩衝池屬資料庫設計。假設讀者具 z/OS 環境 DB2 基礎理解。前幾頁討論效能管理基本概念準則進行「基準設定」。建議綜合性質，非總是詳細技術描述與語法，詳細信息請閱讀本地安裝 DB2 版本最新 IBM 文件。通用設計基準為 DB2 for z/OS V7。雖 V8 已 GA，但大多數客戶需數月才能用於生產系統的 V8 NFM。客戶對基於早期版本驗證的建議更有信心。將提及 V8 部分新特性從效能角度看可能影響設計。免責聲明：資訊未經正式 IBM 測試，以 AS IS 發布，使用風險自負。

效能準則與方法論

1. 何時考慮效能

應用程式與資料庫效能特性考量時機為初期設計階段——開發過程開始時。合理估計所需資源有助於早期做出恰當設計實現決策。等到後期考慮存取資料庫應用程式效能，為取得適當回應時間與批次視窗進行修改會更困難、耗時。

2. 應關注什麼

從效能角度設計時，將精力集中於重要 DB2 資料與程序。確定構成關鍵工作負載的應用程式或事務，以下特徵一條或多條適用：

1. 佔總體業務工作負載很大百分比
2. 有關鍵回應時間需求
3. 包含複雜邏輯和/或資料存取需求
4. 存取大量資料
5. 消耗大量資源
6. 直接面對客戶（Web、ATM 等）相較內部應用

3. 資料庫設計兩階段

• 邏輯資料庫設計：用戶所有資料需求的表示，轉化為範式。通常為資料建模會議輸出。極少原樣實現，僅為考慮實際構造資料前的理想化觀點
• 物理資料庫設計：考慮資料庫對象架構後，邏輯模型轉化為物理模型。此階段詳細考慮資料存取需求與效能因素。兩大要素：表設計與索引設計

4. DB2 效能管理方法

未雨綢缪勝於亡羊補牢。設計早期納入效能因素至關重要。專案盡早建立符合 SLA 的效能「基準線」測量方法，展示與修改時追蹤效能特性與趨勢。持續監控 DB2 系統與應用程式，在大問題全面爆發前預測。許多客戶只在專案最後階段擔心效能，但無理由等待。更好做法：指定使用者介面與處理邏輯後，立即考慮資料庫設計效能特性。如建立最佳索引，以重要 DB2 工作中 SQL 謂詞為主要指南。即使開發有效初期設計，隨資料量增長或資源緊縮仍需修改。效能不合格時，較佳做法通常為現有索引增加欄位或為表新增索引（首選），而非變更表設計、修改用戶需求或反範式化表。

理解 DB2 效能

1. 經驗法則

規劃、監控、優化 DB2 效能時經驗法則很有用，通常基於先前經驗（一段時間觀察平均值）或複雜公式簡化。重要事實：ROT 僅對粗略估計有用，詳細分析用處不大。若只在文件見到 ROT 便盡信引用為精確事實會有危險。最好情況為估計，最壞情況對特定環境不成立。應為自己環境特別開發/調節 ROT，確保與實際經驗相關而非盲目接受。開始可用特定環境外開發的 ROT，但收集分析自己系統資料後應驗證修正。IBM Redbooks 為 ROT 好參考，常作為建議包含在監控工具中。ROT 隨時間演變：硬體技術發展、軟體編程提高、系統架構變化、DB2 新版本釋出均可能降低可靠性甚至失效。

2. DB2 工作負載分類

磁碟 I/O 常為影響回應時間最大因子，但透過 GETPAGE (GP) 請求更易理解底層效能問題。監控 DB2 活動分析報告時，GETPAGE 數量或許為總體工作負載最佳指標。安裝環境下許多 DB2 工作可歸為：

1. 事務：事務管理器 (CICS、IMS/TM) 控制下運行程式。SQL 通常簡單但事務量重。必須提供極佳回應時間。首個調用事務用戶承擔讀取索引/資料頁成本，後續用戶常發現資源已在緩衝池
2. 查詢：決策支援時執行程式。SQL 可能極複雜但工作量遠不及事務。用戶常等待數分鐘至數小時視搜尋資料量。常引起全表掃描，結果排序為常見特徵
3. 批次與實用程式：處理大量資料，常連續方式處理。在給定視窗完成處理很重要。常為系統資源消費大戶，擠在一起常使工作負載逐步上升

3. 正規化

正規化為分析應用程式所需資料實體，轉化為設計良好結構組的格式化過程。邏輯資料模型目標：正確性、一致性、非冗餘、簡單性。關聯理論要求資料庫經正規化。連續編號規則（範式）可詳細定義正規化資料。多數專家建議遵循前三條規則，所得資料符合第三範式。反正規化意為違反表先前遵循的一或多種範式修改設計，常因效能原因進行。關聯資料庫書籍可找到詳細資訊。

4. DB2 表空間類型

定義資料庫中實際表必須在表空間建立。可定義 4 種：

1. 簡單表空間：含一個以上 DB2 表。由頁構成，每頁可含該表空間任何表的行
2. 分段表空間：含一個以上 DB2 表。由頁組 (段) 構成，每段僅含一個表的行
3. 分區表空間：僅含一個表。按分區索引鍵範圍分成多個分區。每分區視為獨立實體，允許 SQL 與實用程式並發處理
4. LOB 表空間：僅用於 LOB 資料 (BLOB、CLOB、DBCLOB)

表空間與表設計考量

1. 記錄大小與頁寬

固定長度記錄優於可變長度，DB2 代碼專為固定長度優化。固定長度無需從初始頁面轉移；可變長度可能不再適合初始頁需轉移，後續存取產生額外頁引用。DB2 UDB V8 新特性允許 ALTER 修改欄位寬度，即使無法確定未來資料長度增長也無需建立可變長度記錄。頁中可存放記錄數值得考慮。DB2 提供 4KB、8KB、16KB、32KB 頁寬選項。開始可選預設 4KB，行長度小或存取基本隨機更應選此。但行長度 > 4KB 需更大頁寬（DB2 不支援跨頁記錄）。行長度略大於 4KB 一半時一頁僅容一行，略大於 1/3、1/4 類似。此設計浪費 DASD 空間且多操作消耗更多資源，應考慮更大頁寬減少相對浪費。頁寬非在 CREATE TABLE 直接指定，由表空間指定緩衝池頁寬決定。詳見 CREATE TABLESPACE 語句。

2. 反正規化考量

邏輯模型為理想藍圖，物理模型為現實實現。正規化只關注資料意義未考慮存取效能需求。完全正規化設計在效能方面受質疑。最常見例為聯結操作：正規化將相關資訊放入不同表，應用需從多表存取。關聯資料庫透過聯結多表從一個以上表存取資訊。聯結可能消耗大量資源時間視表數量與長度。權衡方法：對經常請求欄位的多個表，複製資料與執行表聯結誰成本更高？邏輯設計過程中可無保留正規化，再加入一定程度反正規化作為潛在效能調優選擇。確定反正規化時務必完整文檔化：詳細描述採取步驟背後原因。

3. 設計大型表

存取極大 DB2 表消耗大量資源：CPU、記憶體、I/O。設計大型表提升效能最重要兩件事：實現分區與建立有用索引（下文詳細討論）。

4. 使用分段或分區表空間

含 LOB 資料必須建立 LOB 表空間。非 LOB 資料一般在分區與分段表空間選擇，很大程度取決於儲存資料量，一定長度上取決於應用程式所需存取類型。簡單表空間已少推薦。

分段表空間相對簡單表空間效能優勢：

1. 含多表時，DB2 取得某表鎖不影響其他表段存取
2. 掃描表時僅存取相關段，空段頁不被提取
3. 表被刪除，COMMIT 時段立即可供其他表使用，無需 REORG
4. 表所有行刪除，COMMIT 時所有段立即可用，無需 REORG
5. 大量刪除執行更高效，日誌資訊更少
6. COPY 實用程式不複製大量刪除或 DROP 表造成的空頁

分區表空間潛在優勢（表達一定大小）：

1. 並行性：三種並行方式。查詢並行 (多 I/O 路徑) V3 引入。Sysplex 查詢並行 (資料共享組多用戶/任務) V5 引入。現大幅增強處理分區表空間應用並行能力。增加一定 CPU 時間可大幅減少查詢時間
2. 部分資料操作：實用程式一次處理一分區，其他任務可並發存取其他分區。大量 UPDATE/DELETE/INSERT 可拆分多任務。增加可用性並有潛力減少完成時間
3. 頻繁存取資料更快：分區索引將頻繁存取行與其他行分開，可放入專用分區使用高速 DASD

表越大越有理由建立為分區表。但有時為較小表建立分區表空間也有利：查找表與大分區表聯結時，查找表分區可最大化並行度。聯結謂詞用分區鍵時，需聯結的表應有相同分區數量並在相同值上斷開。

5. 資料壓縮

DB2 提供壓縮表空間或分區資料能力。CREATE TABLESPACE 指定 COMPRESS YES，執行 LOAD 或 REORG 實用程式實現。以較短字串替換經常出現長字串壓縮資料，建立字典映射原始長字串與替換值。儲存前壓縮與讀出時解壓需 CPU 資源。但壓縮帶來效能效益：更少空間 (DASD 與緩衝池) 儲存更多資料，減少同步讀、I/O 等。

決定是否壓縮考量：

1. 行長度：行越長（特別是接近頁寬）壓縮效率越低。DB2 行不跨頁，可能無法實現足夠壓縮使一頁容納多行
2. 表長度：較大表空間壓縮更有效。極小表壓縮字典大小 (8KB-64KB) 可能抵消節省空間
3. 資料模式：重複模式出現頻率決定壓縮效果。大量重複字串有巨大壓縮潛力
4. 壓縮估計：DB2 提供獨立實用程式 DSN1COMP 判斷壓縮效果，詳見 Utilities Guide
5. 處理成本：壓縮/解壓消耗 CPU。IBM 同步資料壓縮硬體比軟體模擬大幅減少 CPU 消耗（DB2 啟動時判斷硬體壓縮特性可用性）