執行摘要
隨著儲存網路化與高度虛擬化，對 DBA 或系統架構師而言，資料庫儲存設計似乎極其複雜。糟糕的儲存設計對資料庫伺服器有極大負面影響：CPU 比實體磁碟快得多，常見效能不佳的資料庫伺服器面臨極密集 I/O，效能表現遠離真實潛力。好消息是，確保儲存設計不犯錯誤比追求完美設計更重要。在虛擬化儲存環境中，試圖理解儲存棧內部結構、手動調優資料庫表與索引在實體磁碟上的位置，對一般 DBA 既難完成也難維護。簡單性是良好儲存設計關鍵。首先確保有足夠實體磁碟，避免系統成為 I/O 密集型。本文介紹透過易學的最佳實踐獲得健全資料庫伺服器的秘訣，涵蓋：實體磁碟與邏輯單元數 (LUN)、條帶與條帶化、交易日誌與資料、檔案系統與原始裝置、RAID 陣列、登錄表變數與配置參數、自動化儲存。
注意：本文最佳實踐適用於常規 OLTP 環境部署 DB2 for Linux, UNIX and Windows。建議不一定適用資料倉庫環境，或 DB2 作為第三方軟體底層資料庫環境。
儲存區域網 (SAN) 與網路連接儲存 (NAS) 根本改變資料庫儲存世界。約十年前「磁碟」指有磁頭碟片的實體磁碟。如今「磁碟」是完全虛擬實體，位於儲存網路上，可以是單一實體磁碟、磁碟一部分、RAID 陣列或組合。檔案系統近期進步（直接與並發 I/O）讓原始裝置相對檔案系統的效能優勢幾乎消失。雖摩爾定律對 CPU 有效，但不適用儲存子系統速度。雖 SAN/NAS 改變儲存通訊，但決定如何儲存位元的底層結構基本不變——機械主軸轉動多個磁性碟片。雖主軸速度提升、儲存控制器 DRAM/NVRAM 緩存有幫助，但無法趕上過去十年處理能力劇增。相對 CPU 處理速度，磁碟慢得多。這種速度差異使每個 CPU 核心須配備越來越多實體磁碟，確保系統不成為 I/O 密集型。雖碟片容量大增，但難達適當磁碟與 CPU 核心比例。隨儲存、檔案系統、CPU 速度變化，資料庫儲存自動配置管理最佳實踐也在演進。過去可能建議 DBA 將表索引放至確切實體磁碟甚至磁碟哪部分。但如今虛擬化儲存世界，對一般 DBA 過去最佳實踐顯得不切實際。本文最佳實踐圍繞現實儲存環境開發。
「使一切盡量簡單，但不過於簡單」——愛因斯坦。設計儲存需做許多選擇，簡單化是架構師與 DBA 秘密武器。本文最佳實踐提出簡單經驗法則，助實現所有目標。簡單化有時付出代價：無法為特定表/表空間選擇最優 I/O 特徵。有豐富儲存技能的資深 DBA 與時間充裕的儲存管理員，常從實體磁碟為特別重要表/索引劃分儲存。問題在於：設計時或取得最佳效能，但為維護初始設計目標，最終往往得到更難管理的系統。問題診斷幾乎總是困難——最初以為足夠的儲存頻寬，隨時間與應用增長變得不夠。良好設計關鍵在於：動態系統上，所有目標在初始設計時滿足，且投入使用時仍然滿足。本文簡單最佳實踐可實現這些目標，幾乎不犧牲效能。
實體磁碟連接儲存控制器，DB2 伺服器等主機系統無法直接存取，DBA 也看不到。儲存管理員以邏輯單元數 (LUN) 形式提供儲存單元，主機系統看到真正 SCSI 磁碟。但 LUN 是儲存管理員提供的完全虛擬實體，可映射實體磁碟任何組合。單一 LUN 可以是單一 RAID 陣列、RAID 陣列一部分、一個實體磁碟、磁碟一部分或多個 RAID 陣列的「元裝置」。雖儲存世界更虛擬化，但事實上資料仍儲存在機械磁碟驅動器上。無論哪家供應商，最終資料仍在機械磁碟驅動器上——旋轉的實體磁碟碟片。LUN 可提供的儲存頻寬與組成它的實際實體磁碟數量成正比。雖儲存控制器緩存可提高頻寬，但 DB2 已將相關資料緩存至緩衝池。這限制儲存控制器充分減少實際實體磁碟需求以支援 DB2 等 I/O 密集型系統的能力。通常 I/O 密集型企業資料庫系統中，最終結果是完全找不到實際實體磁碟替代品。
除傳統 SAN 儲存控制器外，附加儲存虛擬化層正添加至企業，進一步為 DBA 抽象實體磁碟。如 San Volume Controller (SVC)、AIX ViOS。這些虛擬化提供稱心功能增強（透明遷移 LUN、多主機 LPAR 共享 HBA），但付出代價：I/O 路徑出現更多子系統。對 I/O 密集型系統，它們並不減少對實際實體磁碟需求。
磁碟儲存越來越多被視為大宗商品，可用空間常從所在實體設備抽象出來。若企業 I/O 基礎架構要求此類儲存系統，DBA 需繼續確保提供的虛擬 LUN 真正由專用實體磁碟組成。原因：若實際磁碟太少跟不上 CPU 速度，企業系統快變成 I/O 密集型。不幸的是，我們關心資料庫效能的人以實際磁碟數量衡量儲存需求，但儲存管理員不同，他們只按空間概念考慮。雖過去十年碟片大小長足進步，但若要增加每 CPU 核心實體磁碟數而非空間，只會越來越難。更糟的是，DBA 知道需要多少實體磁碟確保良好效能，卻不得不為擁有太多空間辯護。例：1 CPU 核心 20 實體磁碟，磁碟-CPU 比例 1:20 應產生足夠 I/O 平行度提供良好效能。若每磁碟 150GB，每核心約 3TB 空間。多核心按 1:20 配備，總儲存量驚人增長。雖有這麼多「閒置」空間，但這樣儲存並不會過量。例：可能想將未使用空間分配給其他應用/進程。但要記住，競爭應用/進程發出太多 IOPS 可能導致所有應用效能下降。儲存管理員應抵制誘惑，不將未使用空間作為單獨 LUN 分配給 DBA 無法控制的其他應用。現在可在備份至長期儲存前，將未使用空間用作資料庫線上備份或歸檔日誌 staging 區。這非常合理，因執行備份時一切在控制下。換句話說，使用這些設備時完全由您控制。可在不需要峰值 I/O 吞吐量時執行線上備份。若用此策略最大化空間使用率，記住為資料與備份使用相同磁碟不可避免帶來風險。應適時將備份歸檔至外部備份目標（如 Tivoli Storage Manager）。
因 CPU 速度望持續增長（透過增加核心提高平行度而非時脈頻率），預期趨勢：為確保資料庫伺服器不成 I/O 密集型，每系統將需越來越多實體磁碟。因此 DBA 應透過良好模式設計，利用 DB2 進階功能（MDC、MQT、壓縮）盡可能消除 I/O 操作，比以往更重要。相對碟片速度，CPU 處理速度增長更快，好經驗法則：確保每 CPU 核心 15-20 個專用實體磁碟。使用多維叢集 (MDC) 等 I/O 技術、良好模式管理設計，此數字可能減少。註：撰寫時此處實體磁碟數量針對企業普通處理器與磁碟技術（IBM POWER5、Intel Xeon、AMD Opteron，主軸轉速 15000 rpm）。下一代處理器普及時，I/O 密集型資料庫伺服器每處理器將需大量實體磁碟。
最好不在 DB2 伺服器/分區間共享 LUN 與實體磁碟。最佳實踐：每非 DPF DB2 資料庫伺服器與每 DPF 資料庫分區使用專用 LUN。將 LUN 專用於 DB2 伺服器/分區確會阻礙組成該 LUN 的實體磁碟用於建立單獨 LUN，雖建立的 LUN 使用不大可能干擾那些磁碟主要用途。但如前節所述，您應確保這些 LUN 在您控制下並謹慎使用。前文討論將剩餘空間用於備份與歸檔日誌 staging 區屬此類用途。單一檔案系統應在每此類 LUN 上建立，並專用於單一 DB2 伺服器或 DPF 分區。專用 LUN 與每 LUN 專用檔案系統保持儲存佈局簡單性，協助問題診斷。對 DPF 系統，建議遵循 IBM Balanced Configuration Warehouse 實踐。例：表選擇不當分區鍵導致查詢無法獲得應有平行度，採上述做法此問題可輕易診斷。當 LUN 與檔案系統專用於資料庫分區，若見一組 LUN 繁忙時間遠多於其他，問題顯而易見：一個分區存放所有需處理資料，其他分區資料較少。
儲存控制器在控制器韌體中提供傑出 RAID 條帶化。企業系統應設計為使用儲存控制器提供的條帶功能。方便途徑：讓儲存控制器暴露單一 RAID 陣列（如 RAID-5 或 RAID-10）作為單一 LUN，再提供一或多個此類 LUN 給 DB2 分區。當提供不止一個 LUN 給 DB2 伺服器/DPF 分區時，使用 DB2 資料庫系統容器更細條帶。因兩次條帶化對所有系統夠用，避免三次條帶化（如作業系統邏輯卷管理器 LVM）。LVM 條帶化對其他中介軟體有益，但 DB2 系統沒有足夠容量進行自己的條帶化。
為最佳可用性，應將交易日誌與 DB2 資料/表空間分開，放至不同實體磁碟與不同 LUN。每 DB2 分區應提供一個有專用實體磁碟的 LUN 用於交易日誌，此外通常需為表空間容器/資料提供多個 LUN。雖日誌實體磁碟相對資料實體磁碟比例很大程度取決於工作負載，但較好調整準則：15%-25% 實體磁碟用於日誌，75%-85% 用於資料。
因效能原因，直接 I/O 與並發 I/O 已幾乎完全消除使用原始邏輯卷必要性。檔案系統比原始裝置提供更好管理性，因單一檔案系統可作多個表空間容器。為資料庫分區配置的每個 LUN 都應建立單一檔案系統供此分區使用——即每 LUN 一檔案系統。每 DB2 分區通常有：一個交易日誌檔案系統（用 LUN 建立）、多個資料檔案系統（每個用自己單獨 LUN 建立）。
RAID-10 提供極佳冗餘，可經受多次實體磁碟故障。RAID-5 僅能經受一次故障。但 RAID-10 增加冗餘代價是成本比 RAID-5 高很多。若 RAID-10 同時用於日誌與資料，擁有更大不懼磁碟故障韌性。若只能用於二者之一，用於日誌，資料用 RAID-5。若選擇 RAID-5 同時用於二者，仍有非常有韌性的儲存配置；但會發現更大程度依賴資料庫備份。將表空間 EXTENTSIZE 設為 RAID 條帶大小（做不到則設為有助讀取大塊資料的大小）。
RAID 條塊 vs 條帶：RAID 陣列中每實體磁碟上連續資料總量稱「條塊」；橫跨全部條塊組成陣列的資料總量稱「條帶」。典型 RAID 條塊大小 32KB、64KB、128KB。RAID-5 4+1 陣列條帶大小相當於條塊大小 4 倍。表空間 EXTENTSIZE 應設為包含整個 RAID 條帶的頁數。例：RAID-5 4+1 系統條塊 128KB，條帶 512KB (128KB x 4)。若頁大小 8KB，EXTENTSIZE 設 64 (512KB/8KB) 較適合。
有時無法知道給定 DB2 表空間容器的檔案系統儲存在哪個 RAID 陣列。若資料庫伺服器主機與儲存控制器配置的 LUN 間存在其他層或儲存虛擬化，會出現此情況。此時建立表空間時，應將 EXTENTSIZE 設為有利預取程式執行有效大塊 I/O 的數字。較好經驗法則：盤區大小設 256KB。128KB 或 512KB 也不錯。EXTENTSIZE 預設 (32 頁面，由 DFT_EXTENT_SZ 指定) 大多數情況下應提供足夠效能。例：資料庫用 8KB 頁面，不知 RAID 條塊大小細節時，用 32 (8KB x 32 = 256KB) 的 EXTENTSIZE 應足夠。即使 4KB 或 16KB 頁面，32 的 EXTENTSIZE 仍分別得 128KB 或 512KB 盤區大小，符合建議範圍。
預設情況下，表掃描期間，DB2 for Linux, UNIX and Windows 的 I/O 伺服器或預取程式為每個表空間容器執行盤區大小的 I/O。因此 EXTENTSIZE 不僅是 DB2 條帶化單位，也是預取程式連續預取期間使用的讀 I/O 大小。若按上節最佳實踐設定 EXTENTSIZE，則包含每 DB2 容器使用的檔案系統的（單一）RAID 陣列中，應確保一個盤區資料橫跨所有驅動器，然後不需設定 DB2_PARALLEL_IO，因資料庫管理器將自動從容器中所有實體磁碟平行預取該盤區。
除本文方式外，還有其他方式設定 EXTENTSIZE 與設計 DB2 系統條帶化。某些配置中，另一種方式將 EXTENTSIZE 設為使連續資料橫跨每 RAID 陣列中一個實體磁碟——即設為條塊大小而非條帶大小。此配置中，連續預取期間每表空間容器採單一盤區大小 I/O 不適用，因只能驅動檔案系統基於的 RAID 陣列中一個實體磁碟。對這些系統，若想讓資料庫管理器生成多盤區大小預取請求平行驅動每 DB2 表空間容器的實體磁碟，必須設定 DB2_PARALLEL_IO。
DB2_PARALLEL_IO 允許用戶顯式指定每容器下實體磁碟數，為每容器生成適當數量預取請求。例：每表空間容器存在於由 RAID 5 4+1 陣列支援的檔案系統上，合適設定：db2set DB2_PARALLEL_IO=*,5。"*" 表示適用所有表空間。5 表示每容器下有 5 (4+1) 個實體磁碟，每個由單獨預取程式發出的單盤區大小讀請求驅動。演算法考慮 DB2_PARALLEL_IO 設定：CREATE or ALTER TABLESPACE 上 PREFETCHSIZE 選項設 AUTOMATIC 時計算每表空間預取大小；num_iOServers 設 AUTOMATIC 時計算 I/O 伺服器/預取程式數量（參閱「不要手動調優 NUM_IOCLEANERS、NUM_iOSERVERS 和 PREFETCHSIZE 配置參數」）。
NO FILE SYSTEM CACHING 子句支援直接或並發 I/O，任一適合 DB2 所在作業系統平台。直接/並發 I/O 有效使 DB2 I/O 操作在檔案系統上獲得接近原始裝置效能。DB2 Universal Database V8.2 添加支援至 CREATE TABLESPACE 和 ALTER TABLESPACE。V9.5+ 對支援直接/並發 I/O 的檔案系統（JFS2、GPFS、VxFS），新建資料庫預設如此。
DB2 自動化儲存 (AS) 技術是為資料庫配置儲存的簡單有效方式。儲存透過 CREATE DATABASE 直接提供給資料庫，而非表空間。例：
DB2 CREATE DATABASE MYDB ON /data1, /data2, /data3
DBPATH ON /mydbpath此命令建立有 3 個儲存路徑的資料庫：data1、data2、data3。每個路徑為單一檔案系統，每個檔案系統透過專用 LUN 建立。（註：除非另外指定，CREATE DATABASE 建立資料庫時預設使用自動化儲存。）
