執行摘要
隨著存儲的網絡化和高度虛擬化，對於 DBA 或系統架構師來說，數據庫存儲設計似乎是一項極其復雜的任務。
糟糕的數據庫存儲設計對數據庫服務器有極大的負面影響。由於 CPU 比物理磁盤快得多，所以常常可以發現性能糟糕的數據庫服務器，它們面臨非常密集的 I/O ，表現出來的性能離它們的真正潛能差好多倍。
好消息是，保證數據庫存儲的設計不犯錯誤，比獲得完美的數據庫存儲設計更重要。在如今虛擬化存儲的環境中，試圖理解數據存儲棧的內部結構，並手動調優數據庫表和索引在物理磁盤上的存儲位置，這些事情通常既不容易完成，也不易於維護（對於一般的 DBA 而言）。
簡單性是良好數據庫存儲設計的關鍵。首先，要確保有足夠的物理磁盤，以避免系統成為 I/O 密集型系統。
本文介紹通過一些易於學習的數據庫存儲最佳實踐獲得健全數據庫服務器的秘訣，包括以下方面的一些指南和建議：
物理磁盤和邏輯單元數（LUN ）
條帶（Stripe ）和條帶化（striping ）
事務日志和數據
文件系統與原始設備
獨立磁盤冗余陣列（Redundant Array of Independent Disks ，RAID ）設備
注冊表變量和配置參數設置
自動化存儲
注意：本文所述最佳實踐用於在常規 OLTP 環境中部署 DB2 for Linux, UNIX and Windows 。文中討論的建議不一定適用於數據倉庫環境，也不一定適用於將 DB2 數據庫用作第三方軟件底層數據庫的環境。
數據庫存儲簡介
存儲區域網（Storage Area Networks ，SAN ）和網絡連接存儲（Network Attached Storage ，NAS ）從根本上改變了數據庫存儲世界。大約十年前，“磁盤”一詞指的是具有磁頭和碟片的物理磁盤。在如今的存儲世界，“磁盤”是一個完全虛擬的實體，它位於存儲網絡上，可以是單獨的物理磁盤、物理磁盤的一部分、RAID 陣列或者 RAID 陣列的某種組合。
最近在文件系統方面取得的進步，例如直接和並發 I/O ，讓原始設備較之於文件系統的所有性能優勢幾乎消失殆盡。
雖然摩爾定律對 CPU 處理能力有效，但是並不適用於存儲子系統的速度。盡管 SAN 和 NAS 使存儲通信發生了變化，但是決定如何存儲比特的底層結構基本不變 — 機械主軸轉動多個磁性材料的碟片，這些碟片上面是對信息編碼後得到的比特。
雖然主軸速度有所提高，使用 DRAM 和 NVRAM 的存儲控制器上的數據緩存亦有所幫助，但是這些進步都無法趕上過去十年來處理能力的急劇提升。因此，相對於 CPU 的處理速度，磁盤要慢得多。這種速度上的差異使得每個 CPU 核必須配備越來越多的物理磁盤，以確保系統不成為 I/O 密集型系統。雖然決定每個物理磁盤實際容量的碟片容量有了很大的提高，但是仍然難以達到適當的物理磁盤數與 CPU 核的比例。
隨著存儲、文件系統和 CPU 處理速度的變化，數據庫存儲自動配置和管理的最佳實踐也在演變。在過去，可能會建議 DBA 將表和索引放到確切的物理磁盤上，甚至是每個物理磁盤的哪一部分上。但是在如今的虛擬化存儲世界，對於一般 DBA 而言，過去的最佳實踐顯得不切實際。
本文提供的最佳實踐則是圍繞如今現實的存儲環境而開發的。
請參閱“DB2 最佳實踐: 物理數據庫設計最佳實踐”白皮書，獲得關於數據庫性能和數據庫操作速度的相關信息。
良好數據庫存儲設計的目標
良好的數據庫存儲設計必須有以下重要特征：
可預測的 I/O 和系統性能
對 I/O 帶寬和容量的均衡使用 — 避免“熱點（hot-spot ）”
方便的持續管理 — 例如增加新存儲
方便的問題診斷
通過冗余獲得的高可用性
簡單的數據庫存儲設計
“使一切盡量簡單，但是不過於簡單”
– Albert Einstein
在設計數據庫存儲時，需要做出很多的選擇，簡單化是系統架構師和 DBA 的秘密武器。本文提供的最佳實踐提出了一些簡單的經驗法則，它們將有助於實現良好數據庫存儲設計的所有目標。
這種簡單化有時候要付出代價，即不能為特定的表或表空間選擇最優的 I/O 特征。具有豐富存儲技能的有經驗的 DBA ，以及時間充裕的存儲管理員，往往會從物理磁盤中為特別重要的表或索引開辟一片存儲。這種方法存在的問題是，這樣做也許在設計時能取得最佳性能，但是為了維護最初的設計目標，最後往往會得到一個更難以管理的系統。問題診斷幾乎總是很困難——最初認為足夠用於特別重要的表或索引的存儲帶寬，隨著時間的推移和應用程序的增長變得不夠起來。
良好數據庫存儲設計的要點在於，在動態的系統上，所有目標在最初的系統設計時能夠得到滿足，且在數據庫投入使用時仍然如此。本文描述的簡單的最佳實踐可以實現這些目標，且幾乎不會犧牲任何性能。
數據庫存儲成功秘訣
考慮實際的物理磁盤，而不僅僅是存儲空間
物理磁盤與存儲控制器相連，DB2 數據庫服務器等主機系統不能直接訪問它們，DBA 也不能直接看到它們。存儲管理員以邏輯單元數 1 （logical unit numbers ，LUN ）的形式提供存儲單元，而主機系統看到的則是真正的 SCSI 磁盤。但是，LUN 是由存儲管理員提供的完全虛擬的實體，可映射物理磁盤的任何組合。一個 LUN 可以是單一 RAID 陣列、RAID 陣列的一部分、一個物理磁盤、磁盤的一部分或者多個 RAID 陣列的“元設備（meta ）”。
雖然存儲世界變得更加虛擬化，但事實上數據仍然存儲在機械磁盤驅動器上。無論使用哪家供應商的存儲子系統，最終數據仍存儲在機械磁盤驅動器上，也就是旋轉的物理磁盤碟片上。LUN 可提供的存儲帶寬與組成它的實際物理磁盤的數量成正比。
雖然存儲控制器緩存可幫助提高存儲帶寬，但 DB2 數據庫系統已經將相關數據緩存到它們的緩沖池中。這限制了存儲控制器充分減少實際物理磁盤需求，以支持 DB2 數據庫服務器等 I/O 密集型系統的能力。在通常為 I/O 密集型的企業數據庫系統中，最終結果是完全找不到實際物理磁盤的替代品。
除了傳統的 SAN 存儲控制器外，附加的存儲虛擬化層也正在被添加到企業中，它們進一步為 DBA 抽象物理磁盤。這種虛擬化的例子有 San Volume Controller (SVC) 和 AIX® ViOS 。這些形式的虛擬化可提供稱心的功能增強，例如透明地從一組 LUN 向另一組 LUN 遷移的能力，或者多個主機 LPAR 共享一條光纖通道 Host Bus Adapter (HBA) 的能力。但是，這樣做需要付出一定的代價，通常包括 I/O 路徑中出現更多的子系統。此外，對於 I/O 密集型系統，它們並不能減少對實際物理磁盤的需求。
處理高度虛擬化的存儲
如本文簡介部分所述，磁盤存儲越來越多地被當做一種普通用品，可用存儲空間常常被從其所在物理設備中抽象出來。
如果您的企業的 I/O 基礎結構要求使用這樣的存儲系統，那麼 DBA 需要繼續確保所提供的虛擬 LUN 真正由專用的物理磁盤組成。原因是：如果實際磁盤太少，跟不上 CPU 的速度，那麼企業系統很快會變成 I/O 密集型系統。不幸的是，雖然我們這些關心數據庫性能的人是以實際磁盤數量來衡量存儲需求的，但存儲管理員卻不同，他們只按空間的概念來考慮存儲需求。雖然過去十來年碟片大小有了長足的進步，但若要增加每個 CPU 核的物理磁盤數而不僅僅是空間，只會變得越來越難。
更糟糕的是，數據庫管理員知道需要多少物理磁盤來確保良好性能，卻不得不為擁有太多空間而辯護。例如，假設有一個 CPU 核和 20 個物理磁盤。這樣的磁盤 -CPU 比例應該可以產生足夠的 I/O 並行性來提供很好的性能。如果每個磁盤設備可以存儲 150 GB ，那麼每個 CPU 核有大約 3 TB 的空間。如果有多個 CPU 核，每個核按 1:20 的比例配備物理磁盤，那麼存儲的總量將以驚人的速度增長。
雖然有這麼多“空閒”的空間，但重要的是這樣的存儲並不會過量。例如，您可能想將一些未使用的存儲分配給其他應用程序或進程。但是要記住，相互競爭的應用程序或進程發出太多的每秒 I/O 操作（I/O-Operations-per-second ，IOPS ）可能導致所有應用程序的性能下降。這意味著存儲管理員應該抵制誘惑，不要將未使用的空間作為單獨的 LUN 分配給 DBA 無權控制的其他應用程序。
現在，可以在將數據庫備份到長期存儲之前，將未使用的空間用作數據庫在線備份或歸檔日志的 staging 區域。這是非常合理的用法，因為當執行備份時，一切都在您的控制之下。換句話說，當使用這些設備時，完全由您（而不是其他未知的用戶或應用程序）控制。您可以在不需要峰值 I/O 吞吐量的時候執行在線備份。
如果使用這樣的策略來最大化空間使用率，那麼要記住，為數據和備份使用相同的磁盤將不可避免地帶來一定的風險。應該適時地將備份歸檔到外部備份目標，例如 Tivoli® Storage Manager (TSM) 。
由於 CPU 速度有望繼續增長（增長方式是通過增加 CPU 核提高處理並行性，而不是增加時鐘頻率），預期的趨勢是，為確保數據庫服務器不成為 I/O 密集型系統，每個系統將需要越來越多的物理磁盤。因此，DBA 應通過良好的模式設計，並利用 DB2 數據庫系統中的高級功能，例如 MDC 、MQT 和壓縮，盡可能消除 I/O 操作，這一點比以往更重要。
相對於碟片速度，CPU 處理速度有了更快的增長，因此好的經驗法則是確保每個 CPU 核有 15 到 20 個專用物理磁盤。通過使用多維集群（Multidimensional Clustering ，MDC ）等 I/O 技術，以及良好的模式管理和設計，這個數字有可能減少。
值得注意的是，在撰寫本文之際，此處所說的物理磁盤數量只針對企業中的普通處理器和磁盤技術。這包括 IBM POWER5 ™、Intel® Xeon® 和 AMD® Opteron ™ 處理器。普通的主軸速度是 15000 rpm 。當下一代處理器普及時，對於 I/O 密集型數據庫服務器，每個處理器將需要大量的物理磁盤。
為每個非 DPF DB2 數據庫服務器 / 每個 DPF 分區使用專用 LUN 和文件系統
最好不要在 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 的繁忙時間遠多於其他 LUN ，那麼這個問題就變得很明顯了，因為一個分區上存放了所有需要處理的數據，而其他分區上的數據則相對較少。
最多兩次條帶化
存儲控制器直接在控制器固件中提供了傑出的 RAID 條帶化。應該將企業系統設計為使用存儲控制器提供的條帶功能。這麼做的一個更方便的途徑是讓存儲控制器暴露一個單獨的 RAID 陣列，例如，讓 RAID-5 或 RAID-10 作為一個單獨的 LUN 。然後，可以將一個或多個這樣的 LUN 提供給 DB2 分區。
當把不止一個 LUN 提供給 DB2 數據庫服務器或 DPF 數據庫分區時，則使用 DB2 數據庫系統容器更細的條帶。
由於兩次條帶化對所有的系統都算足夠了，要避免使用三次條帶化，例如操作系統的邏輯卷管理器。邏輯卷管理器（LVM ）條帶化對於其他中間件有益，但是 DB2 數據庫系統不同，DB2 數據庫系統中沒有足夠的容量來進行自己的條帶化。
將 DB2 事務日志與數據分開
為取得最佳可用性，應將事務日志和 DB2 數據或表空間分開，放到不同的物理磁盤和不同的 LUN 上。
應該為每個 DB2 分區提供一個有專用物理磁盤的 LUN 用於事務日志，此外，通常還需為表空間容器或數據提供多個 LUN 。
雖然日志物理磁盤相對於數據物理磁盤的比例很大程度上取決於工作負載，但較好的調整准則是 15% 至 25% 的物理磁盤用於日志，75% 至 85% 的物理磁盤用於數據。
使用文件系統替代原始設備 — 為每個 LUN 創建一個文件系統
由於性能的原因，直接 I/O 和並發 I/O 幾乎已經完全消除了使用原始邏輯卷的需要。文件系統比原始設備提供更好的可管理性，因為單個文件系統可用作多個表空間的容器。
為一個數據庫分區配置的的每個 LUN 都應該創建一個單獨的文件系統，供這個分區使用，也就是說，每個 LUN 一個文件系統。
每個 DB2 分區通常有：
一個事物日志文件系統 — 使用 LUN 創建，用於分區的事務日志。
多個數據文件系統——每個文件系統都使用它自己單獨的 LUN 創建，用於表空間數據。
事務日志使用 RAID-10，數據使用 RAID-10 或 RAID-5
RAID-10 提供極好的冗余，因為它可以經受多次物理磁盤故障。而 RAID-5 只能經受一次物理磁盤故障。但是，RAID-10 增加冗余的代價是成本比 RAID-5 高很多。
如果將 RAID-10 同時用於日志和數據，那麼將擁有更大的不懼磁盤故障的韌性。如果只能將 RAID-10 用於存儲數據或日志中的一種，那麼將它用於日志，而將 RAID-5 用於數據。如果選擇將 RAID-5 同時用於日志和數據，那麼仍然可以擁有非常有韌性的存儲配置；但是，您會發現需要更大程度上依賴於數據庫備份。將表空間 EXTENTSIZE 設置為 RAID 條帶大小（如果做不到，則設為一個有助於讀取大塊數據的大小）。
RAID 陣列中每個物理磁盤上連續數據的總量稱作“條塊（strip ）”，橫跨這些全部由條塊組成的陣列的數據的總量則稱作“條帶（stripe ）”。
典型的 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 的數字。較好的經驗法則是將盤區大小設為 256 KB 。 128 KB 或 512 KB 的盤區大小也是不錯的選擇。
EXTENTSIZE 的默認設置（32 個頁面，由 DFT_EXTENT_SZ 配置參數指定）大多數情況下應該能提供足夠的性能。例如，如果數據庫使用 8 KB 的頁面，在不知道 RAID 條塊大小方面的詳細信息時，使用 32 （8 KB x 32 個頁面 = 256 KB ）的 EXTENTSIZE 應該足夠了。即使對於 4 KB 或 16 KB 的頁面，32 的 EXTENTSIZE 仍可以分別得到 128 KB 或 512 KB 的盤區大小，這符合建議的范圍。
設置 DB2_PARALLEL_IO 實現最佳 I/O 並行性
默認情況下，在表掃描期間，DB2 for Linux, UNIX and Windows 的 I/O 服務器或預取程序為每個表空間容器執行盤區大小的 I/O 。因此，EXTENTSIZE 不僅是 DB2 的條帶化單位，也是預取程序在連續預取期間使用的讀 I/O 大小。
如果按照上一節中的最佳實踐設置 EXTENTSIZE ，那麼在包含每個 DB2 容器使用的文件系統的（單個）RAID 陣列中，應確保一個盤區的數據橫跨所有的驅動器，然後就不需要設置 DB2_PARALLEL_IO 了，因為數據庫管理器將自動從容器中的所有物理磁盤中並行地預取該盤區。
除了本文提供的方式外，還有其他方式可用於設置 EXTENTSIZE 和設計 DB2 系統的條帶化。
在某些配置中，另一種方式是將 EXTENTSIZE 設為使連續數據橫跨每個 RAID 陣列中的一個物理磁盤。也就是說，將 EXTENTSIZE 設為條塊大小，而不是上一節推薦的條帶大小。在這樣的配置中，在連續預取期間，每個表空間容器采用單個盤區大小的 I/O 便不適用，因為它只能驅動文件系統所基於的 RAID 陣列中的一個物理磁盤。對於這些系統，如果想讓數據庫管理器生成多盤區大小的預取請求，並行地驅動用於每個 DB2 表空間容器的物理磁盤，就必須設置 DB2_PARALLEL_IO 。
DB2_PARALLEL_IO 允許用戶顯式地指定每個容器下的物理磁盤數，以便為每個容器生成適當數量的預取請求。例如，如果每個表空間容器存在於一個由 RAID 5 4+1 陣列支持的文件系統上，那麼下面是合適的 DB2_PARALLEL_ IO 設置：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 子句
NO FILE SYSTEM CACHING 子句支持直接或並發 I/O ，其中任何一個都適合 DB2 數據庫系統所在的操作系統平台。直接或並發 I/O 有效地使 DB2 I/O 操作在文件系統上獲得接近原始設備的性能。
在 DB2 Universal Database, Version 8.2 中，對 NO FILE SYSTEM CACHING 子句的支持已經被添加到 CREATE TABLESPACE 和 ALTER TABLESPACE 語句中。從 Version 9.5 開始，對於那些支持直接或並發 I/O 的文件系統，例如 JFS2 、GPFS™ 和 VxFS ，新創建的數據庫已默認如此。
使用 DB2 自動化存儲讓條帶化無處不在
DB2 自動化存儲（AS ）技術是為數據庫配置存儲的一種簡單而有效的方式。存儲通過 CREATE DATABASE 命令直接提供給數據庫，而非表空間。例如：
DB2 CREATE DATABASE MYDB ON /data1, /data2, /data3
DBPATH ON /mydbpath
這個例子命令創建一個數據庫，它有 3 個存儲路徑：data1 、data2 和 data3 。每個路徑都是一個單獨的文件系統，每個文件系統都是通過專用的 LUN 創建的。（注意：除非另外指定，否則在使用 CREATE DATABASE 命令創建數據庫時將默認使用自動化存儲。）
