DB2最佳實踐DB2數(shù)據(jù)庫存儲機制

1、DB2 最佳實踐: DB2 數(shù)據(jù)庫存儲機制執(zhí)行摘要隨著存儲的網(wǎng)絡化和高度虛擬化，對于 DBA 或系統(tǒng)架構(gòu)師來說，數(shù)據(jù)庫存儲設計似乎是一項極其復雜的任務。糟糕的數(shù)據(jù)庫存儲設計對數(shù)據(jù)庫服務器有極大的負面影響。由于 CPU 比物理磁盤快得多，所以常?？梢园l(fā)現(xiàn)性能糟糕的數(shù)據(jù)庫服務器，它們面臨非常密集的 I/O ，表現(xiàn)出來的性能離它們的真正潛能差好多倍。好消息是，保證數(shù)據(jù)庫存儲的設計不犯錯誤，比獲得完美的數(shù)據(jù)庫存儲設計更重要。在如今虛擬化存儲的環(huán)境中，試圖理解數(shù)據(jù)存儲棧的內(nèi)部結(jié)構(gòu)，并手動調(diào)優(yōu)數(shù)據(jù)庫表和索引在物理磁盤上的存儲位置，這些事情通常既不容易完成，也不易于維護（對于一般的 DBA 而言）。簡單性是

2、良好數(shù)據(jù)庫存儲設計的關(guān)鍵。首先，要確保有足夠的物理磁盤，以避免系統(tǒng)成為 I/O 密集型系統(tǒng)。本文介紹通過一些易于學習的數(shù)據(jù)庫存儲最佳實踐獲得健全數(shù)據(jù)庫服務器的秘訣，包括以下方面的一些指南和建議：· 物理磁盤和邏輯單元數(shù)（LUN ）· 條帶（Stripe ）和條帶化（striping ）· 事務日志和數(shù)據(jù)· 文件系統(tǒng)與原始設備· 獨立磁盤冗余陣列（Redundant Array of Independent Disks ，RAID ）設備· 注冊表變量和配置參數(shù)設置· 自動化存儲注意：本文所述最佳實踐用于在常規(guī) OLTP 環(huán)境

3、中部署 DB2 for Linux, UNIX and Windows 。文中討論的建議不一定適用于數(shù)據(jù)倉庫環(huán)境，也不一定適用于將 DB2 數(shù)據(jù)庫用作第三方軟件底層數(shù)據(jù)庫的環(huán)境。數(shù)據(jù)庫存儲簡介存儲區(qū)域網(wǎng)（Storage Area Networks ，SAN ）和網(wǎng)絡連接存儲（Network Attached Storage ，NAS ）從根本上改變了數(shù)據(jù)庫存儲世界。大約十年前，“磁盤”一詞指的是具有磁頭和碟片的物理磁盤。在如今的存儲世界，“磁盤”是一個完全虛擬的實體，它位于存儲網(wǎng)絡上，可以是單獨的物理磁盤、物理磁盤的一部分、RAID 陣列或者 RAID 陣列的某種組合。最近在文件系統(tǒng)方面取得的

4、進步，例如直接和并發(fā) I/O ，讓原始設備較之于文件系統(tǒng)的所有性能優(yōu)勢幾乎消失殆盡。雖然摩爾定律對 CPU 處理能力有效，但是并不適用于存儲子系統(tǒng)的速度。盡管 SAN 和 NAS 使存儲通信發(fā)生了變化，但是決定如何存儲比特的底層結(jié)構(gòu)基本不變 機械主軸轉(zhuǎn)動多個磁性材料的碟片，這些碟片上面是對信息編碼后得到的比特。雖然主軸速度有所提高，使用 DRAM 和 NVRAM 的存儲控制器上的數(shù)據(jù)緩存亦有所幫助，但是這些進步都無法趕上過去十年來處理能力的急劇提升。因此，相對于 CPU 的處理速度，磁盤要慢得多。這種速度上的差異使得每個 CPU 核必須配備越來越多的物理磁盤，以確保系統(tǒng)不成為 I/O 密集型系

5、統(tǒng)。雖然決定每個物理磁盤實際容量的碟片容量有了很大的提高，但是仍然難以達到適當?shù)奈锢泶疟P數(shù)與 CPU 核的比例。隨著存儲、文件系統(tǒng)和 CPU 處理速度的變化，數(shù)據(jù)庫存儲自動配置和管理的最佳實踐也在演變。在過去，可能會建議 DBA 將表和索引放到確切的物理磁盤上，甚至是每個物理磁盤的哪一部分上。但是在如今的虛擬化存儲世界，對于一般 DBA 而言，過去的最佳實踐顯得不切實際。本文提供的最佳實踐則是圍繞如今現(xiàn)實的存儲環(huán)境而開發(fā)的。請參閱“DB2 最佳實踐: 物理數(shù)據(jù)庫設計最佳實踐”白皮書，獲得關(guān)于數(shù)據(jù)庫性能和數(shù)據(jù)庫操作速度的相關(guān)信息。該白皮書和其他相關(guān)資料可從 DB2 最佳實踐專題 獲得。良好數(shù)據(jù)庫

6、存儲設計的目標良好的數(shù)據(jù)庫存儲設計必須有以下重要特征：· 可預測的 I/O 和系統(tǒng)性能· 對 I/O 帶寬和容量的均衡使用 避免“熱點（hot-spot ）”· 方便的持續(xù)管理 例如增加新存儲· 方便的問題診斷· 通過冗余獲得的高可用性簡單的數(shù)據(jù)庫存儲設計“使一切盡量簡單，但是不過于簡單” Albert Einstein在設計數(shù)據(jù)庫存儲時，需要做出很多的選擇，簡單化是系統(tǒng)架構(gòu)師和 DBA 的秘密武器。本文提供的最佳實踐提出了一些簡單的經(jīng)驗法則，它們將有助于實現(xiàn)良好數(shù)據(jù)庫存儲設計的所有目標。這種簡單化有時候要付出代價，即不能為特定的表或表空間選擇

7、最優(yōu)的 I/O 特征。具有豐富存儲技能的有經(jīng)驗的 DBA ，以及時間充裕的存儲管理員，往往會從物理磁盤中為特別重要的表或索引開辟一片存儲。這種方法存在的問題是，這樣做也許在設計時能取得最佳性能，但是為了維護最初的設計目標，最后往往會得到一個更難以管理的系統(tǒng)。問題診斷幾乎總是很困難最初認為足夠用于特別重要的表或索引的存儲帶寬，隨著時間的推移和應用程序的增長變得不夠起來。良好數(shù)據(jù)庫存儲設計的要點在于，在動態(tài)的系統(tǒng)上，所有目標在最初的系統(tǒng)設計時能夠得到滿足，且在數(shù)據(jù)庫投入使用時仍然如此。本文描述的簡單的最佳實踐可以實現(xiàn)這些目標，且?guī)缀醪粫奚魏涡阅?。?shù)據(jù)庫存儲成功秘訣考慮實際的物理磁盤，而不僅僅是

8、存儲空間物理磁盤與存儲控制器相連，DB2 數(shù)據(jù)庫服務器等主機系統(tǒng)不能直接訪問它們，DBA 也不能直接看到它們。存儲管理員以邏輯單元數(shù) 1 （logical unit numbers ，LUN ）的形式提供存儲單元，而主機系統(tǒng)看到的則是真正的 SCSI 磁盤。但是，LUN 是由存儲管理員提供的完全虛擬的實體，可映射物理磁盤的任何組合。一個 LUN 可以是單一 RAID 陣列、RAID 陣列的一部分、一個物理磁盤、磁盤的一部分或者多個 RAID 陣列的“元設備（meta ）”。雖然存儲世界變得更加虛擬化，但事實上數(shù)據(jù)仍然存儲在機械磁盤驅(qū)動器上。無論使用哪家供應商的存儲子系統(tǒng)，最終數(shù)據(jù)仍存儲在機械磁

9、盤驅(qū)動器上，也就是旋轉(zhuǎn)的物理磁盤碟片上。LUN 可提供的存儲帶寬與組成它的實際物理磁盤的數(shù)量成正比。雖然存儲控制器緩存可幫助提高存儲帶寬，但 DB2 數(shù)據(jù)庫系統(tǒng)已經(jīng)將相關(guān)數(shù)據(jù)緩存到它們的緩沖池中。這限制了存儲控制器充分減少實際物理磁盤需求，以支持 DB2 數(shù)據(jù)庫服務器等 I/O 密集型系統(tǒng)的能力。在通常為 I/O 密集型的企業(yè)數(shù)據(jù)庫系統(tǒng)中，最終結(jié)果是完全找不到實際物理磁盤的替代品。除了傳統(tǒng)的 SAN 存儲控制器外，附加的存儲虛擬化層也正在被添加到企業(yè)中，它們進一步為 DBA 抽象物理磁盤。這種虛擬化的例子有 San Volume Controller (SVC) 和 AIX® VIO

10、S 。這些形式的虛擬化可提供稱心的功能增強，例如透明地從一組 LUN 向另一組 LUN 遷移的能力，或者多個主機 LPAR 共享一條光纖通道 Host Bus Adapter (HBA) 的能力。但是，這樣做需要付出一定的代價，通常包括 I/O 路徑中出現(xiàn)更多的子系統(tǒng)。此外，對于 I/O 密集型系統(tǒng)，它們并不能減少對實際物理磁盤的需求。處理高度虛擬化的存儲如本文簡介部分所述，磁盤存儲越來越多地被當做一種普通用品，可用存儲空間常常被從其所在物理設備中抽象出來。如果您的企業(yè)的 I/O 基礎結(jié)構(gòu)要求使用這樣的存儲系統(tǒng)，那么 DBA 需要繼續(xù)確保所提供的虛擬 LUN 真正由專用的物理磁盤組成。原因是：

11、如果實際磁盤太少，跟不上 CPU 的速度，那么企業(yè)系統(tǒng)很快會變成 I/O 密集型系統(tǒng)。不幸的是，雖然我們這些關(guān)心數(shù)據(jù)庫性能的人是以實際磁盤數(shù)量來衡量存儲需求的，但存儲管理員卻不同，他們只按空間的概念來考慮存儲需求。雖然過去十來年碟片大小有了長足的進步，但若要增加每個 CPU 核的物理磁盤數(shù)而不僅僅是空間，只會變得越來越難。更糟糕的是，數(shù)據(jù)庫管理員知道需要多少物理磁盤來確保良好性能，卻不得不為擁有太多空間而辯護。例如，假設有一個 CPU 核和 20 個物理磁盤。這樣的磁盤 -CPU 比例應該可以產(chǎn)生足夠的 I/O 并行性來提供很好的性能。如果每個磁盤設備可以存儲 150 GB ，那么每個 CPU

12、 核有大約 3 TB 的空間。如果有多個 CPU 核，每個核按 1:20 的比例配備物理磁盤，那么存儲的總量將以驚人的速度增長。雖然有這么多“空閑”的空間，但重要的是這樣的存儲并不會過量。例如，您可能想將一些未使用的存儲分配給其他應用程序或進程。但是要記住，相互競爭的應用程序或進程發(fā)出太多的每秒 I/O 操作（I/O-operations-per-second ，IOPS ）可能導致所有應用程序的性能下降。這意味著存儲管理員應該抵制誘惑，不要將未使用的空間作為單獨的 LUN 分配給 DBA 無權(quán)控制的其他應用程序?，F(xiàn)在，可以在將數(shù)據(jù)庫備份到長期存儲之前，將未使用的空間用作數(shù)據(jù)庫在線備份或歸檔日

13、志的 staging 區(qū)域。這是非常合理的用法，因為當執(zhí)行備份時，一切都在您的控制之下。換句話說，當使用這些設備時，完全由您（而不是其他未知的用戶或應用程序）控制。您可以在不需要峰值 I/O 吞吐量的時候執(zhí)行在線備份。如果使用這樣的策略來最大化空間使用率，那么要記住，為數(shù)據(jù)和備份使用相同的磁盤將不可避免地帶來一定的風險。應該適時地將備份歸檔到外部備份目標，例如 Tivoli® Storage Manager (TSM) 。由于 CPU 速度有望繼續(xù)增長（增長方式是通過增加 CPU 核提高處理并行性，而不是增加時鐘頻率），預期的趨勢是，為確保數(shù)據(jù)庫服務器不成為 I/O 密集型系統(tǒng)，每個

14、系統(tǒng)將需要越來越多的物理磁盤。因此，DBA 應通過良好的模式設計，并利用 DB2 數(shù)據(jù)庫系統(tǒng)中的高級功能，例如 MDC 、MQT 和壓縮，盡可能消除 I/O 操作，這一點比以往更重要。相對于碟片速度，CPU 處理速度有了更快的增長，因此好的經(jīng)驗法則是確保每個 CPU 核有 15 到 20 個專用物理磁盤。通過使用多維集群（Multidimensional Clustering ，MDC ）等 I/O 技術(shù)，以及良好的模式管理和設計，這個數(shù)字有可能減少。值得注意的是，在撰寫本文之際，此處所說的物理磁盤數(shù)量只針對企業(yè)中的普通處理器和磁盤技術(shù)。這包括 IBM POWER5 、Intel®

15、Xeon® 和 AMD® Opteron 處理器。普通的主軸速度是 15000 rpm 。當下一代處理器普及時，對于 I/O 密集型數(shù)據(jù)庫服務器，每個處理器將需要大量的物理磁盤。為每個非 DPF DB2 數(shù)據(jù)庫服務器 / 每個 DPF 分區(qū)使用專用 LUN 和文件系統(tǒng)最好不要在 DB2 服務器 / 分區(qū)之間共享 LUN 和物理磁盤。最佳實踐是為每個非 DPF DB2 數(shù)據(jù)庫服務器和每個 DPF 數(shù)據(jù)庫分區(qū)使用專用 LUN 。將 LUN 專用于 DB2 服務器或分區(qū)確實會阻礙將組成該 LUN 的物理磁盤用于創(chuàng)建單獨的 LUN ，雖然創(chuàng)建的 LUN 的使用不大可能干擾那些磁盤的

16、主要用途。但是，如上一節(jié)所述，您應該確保這些 LUN 在您的控制之下，并謹慎地加以使用。之前討論的將剩余空間用于備份和歸檔日志的 staging 區(qū)域就屬于這樣的用途。單個的文件系統(tǒng)應該在每個這樣的 LUN 上創(chuàng)建，并且應該專用于單個 DB2 服務器或 DPF 數(shù)據(jù)庫分區(qū)。專用的 LUN 和每個 LUN 上專用的文件系統(tǒng)可保持存儲布局的簡單性，并且有助于問題診斷。對于 DPF 系統(tǒng)，建議遵循 IBM Balanced Configuration Warehouse 實踐。例如，當在一個表上選擇了不恰當?shù)姆謪^(qū)鍵時，查詢便不能獲得應有的并行性，如果采用上述做法，這個問題就可輕易診斷出來。當 LUN

17、 和文件系統(tǒng)專用于數(shù)據(jù)庫分區(qū)時，如果看到一組 LUN 的繁忙時間遠多于其他 LUN ，那么這個問題就變得很明顯了，因為一個分區(qū)上存放了所有需要處理的數(shù)據(jù)，而其他分區(qū)上的數(shù)據(jù)則相對較少。最多兩次條帶化存儲控制器直接在控制器固件中提供了杰出的 RAID 條帶化。應該將企業(yè)系統(tǒng)設計為使用存儲控制器提供的條帶功能。這么做的一個更方便的途徑是讓存儲控制器暴露一個單獨的 RAID 陣列，例如，讓 RAID-5 或 RAID-10 作為一個單獨的 LUN 。然后，可以將一個或多個這樣的 LUN 提供給 DB2 分區(qū)。當把不止一個 LUN 提供給 DB2 數(shù)據(jù)庫服務器或 DPF 數(shù)據(jù)庫分區(qū)時，則使用 DB2

18、數(shù)據(jù)庫系統(tǒng)容器更細的條帶。由于兩次條帶化對所有的系統(tǒng)都算足夠了，要避免使用三次條帶化，例如操作系統(tǒng)的邏輯卷管理器。邏輯卷管理器（LVM ）條帶化對于其他中間件有益，但是 DB2 數(shù)據(jù)庫系統(tǒng)不同，DB2 數(shù)據(jù)庫系統(tǒng)中沒有足夠的容量來進行自己的條帶化。將 DB2 事務日志與數(shù)據(jù)分開為取得最佳可用性，應將事務日志和 DB2 數(shù)據(jù)或表空間分開，放到不同的物理磁盤和不同的 LUN 上。應該為每個 DB2 分區(qū)提供一個有專用物理磁盤的 LUN 用于事務日志，此外，通常還需為表空間容器或數(shù)據(jù)提供多個 LUN 。雖然日志物理磁盤相對于數(shù)據(jù)物理磁盤的比例很大程度上取決于工作負載，但較好的調(diào)整準則是 15% 至

19、25% 的物理磁盤用于日志，75% 至 85% 的物理磁盤用于數(shù)據(jù)。使用文件系統(tǒng)替代原始設備 為每個 LUN 創(chuàng)建一個文件系統(tǒng)由于性能的原因，直接 I/O 和并發(fā) I/O 幾乎已經(jīng)完全消除了使用原始邏輯卷的需要。文件系統(tǒng)比原始設備提供更好的可管理性，因為單個文件系統(tǒng)可用作多個表空間的容器。為一個數(shù)據(jù)庫分區(qū)配置的的每個 LUN 都應該創(chuàng)建一個單獨的文件系統(tǒng)，供這個分區(qū)使用，也就是說，每個 LUN 一個文件系統(tǒng)。每個 DB2 分區(qū)通常有：· 一個事物日志文件系統(tǒng) 使用 LUN 創(chuàng)建，用于分區(qū)的事務日志。· 多個數(shù)據(jù)文件系統(tǒng)每個文件系統(tǒng)都使用它自己單獨的 LUN 創(chuàng)建，用于表空間

20、數(shù)據(jù)。事務日志使用 RAID-10，數(shù)據(jù)使用 RAID-10 或 RAID-5RAID-10 提供極好的冗余，因為它可以經(jīng)受多次物理磁盤故障。而 RAID-5 只能經(jīng)受一次物理磁盤故障。但是，RAID-10 增加冗余的代價是成本比 RAID-5 高很多。如果將 RAID-10 同時用于日志和數(shù)據(jù)，那么將擁有更大的不懼磁盤故障的韌性。如果只能將 RAID-10 用于存儲數(shù)據(jù)或日志中的一種，那么將它用于日志，而將 RAID-5 用于數(shù)據(jù)。如果選擇將 RAID-5 同時用于日志和數(shù)據(jù)，那么仍然可以擁有非常有韌性的存儲配置；但是，您會發(fā)現(xiàn)需要更大程度上依賴于數(shù)據(jù)庫備份。將表空間 EXTENTSIZE

21、設置為 RAID 條帶大?。ㄈ绻霾坏?，則設為一個有助于讀取大塊數(shù)據(jù)的大?。?。RAID 陣列中每個物理磁盤上連續(xù)數(shù)據(jù)的總量稱作“條塊（strip ）”，橫跨這些全部由條塊組成的陣列的數(shù)據(jù)的總量則稱作“條帶（stripe ）”。典型的 RAID 條塊大小是 32kb 、64kb 、128kb 等。RAID-5 4+1 陣列上的條帶大小相當于條塊大小的 4 倍。表空間的 EXTENTSIZE 應該設為包括整個 RAID 條帶的頁數(shù)。例如，一個使用 RAID-5 4+1 的系統(tǒng)，其條塊大小為 128kb ，那么該系統(tǒng)上的條帶大小為 512kb （128kb x 4 ）。如果使用的頁大小為 8kb ，

22、那么將 EXTENTSIZE 設為 64 （512kb/8kb ）較為合適。在虛擬化存儲環(huán)境中設置表空間盤區(qū)大小有時候，無法知道給定 DB2 表空間容器的文件系統(tǒng)存儲在哪個 RAID 陣列上。如果為數(shù)據(jù)庫服務器主機和存儲控制器配置的 LUN 之間存在其他層或存儲虛擬化，那么就會出現(xiàn)這種情況。在此情況下，當創(chuàng)建表空間時，應該將 EXTENTSIZE 設為一個有利于預取程序執(zhí)行有效大塊 I/O 的數(shù)字。較好的經(jīng)驗法則是將盤區(qū)大小設為 256 KB 。 128 KB 或 512 KB 的盤區(qū)大小也是不錯的選擇。EXTENTSIZE 的默認設置（32 個頁面，由 DFT_EXTENT_SZ 配置參數(shù)指

23、定）大多數(shù)情況下應該能提供足夠的性能。例如，如果數(shù)據(jù)庫使用 8 KB 的頁面，在不知道 RAID 條塊大小方面的詳細信息時，使用 32 （8 KB x 32 個頁面 = 256 KB ）的 EXTENTSIZE 應該足夠了。即使對于 4 KB 或 16 KB 的頁面，32 的 EXTENTSIZE 仍可以分別得到 128 KB 或 512 KB 的盤區(qū)大小，這符合建議的范圍。設置 DB2_PARALLEL_IO 實現(xiàn)最佳 I/O 并行性默認情況下，在表掃描期間，DB2 for Linux, UNIX and Windows 的 I/O 服務器或預取程序為每個表空間容器執(zhí)行盤區(qū)大小的 I/O 。

24、因此，EXTENTSIZE 不僅是 DB2 的條帶化單位，也是預取程序在連續(xù)預取期間使用的讀 I/O 大小。如果按照上一節(jié)中的最佳實踐設置 EXTENTSIZE ，那么在包含每個 DB2 容器使用的文件系統(tǒng)的（單個）RAID 陣列中，應確保一個盤區(qū)的數(shù)據(jù)橫跨所有的驅(qū)動器，然后就不需要設置 DB2_PARALLEL_IO 了，因為數(shù)據(jù)庫管理器將自動從容器中的所有物理磁盤中并行地預取該盤區(qū)。除了本文提供的方式外，還有其他方式可用于設置 EXTENTSIZE 和設計 DB2 系統(tǒng)的條帶化。在某些配置中，另一種方式是將 EXTENTSIZE 設為使連續(xù)數(shù)據(jù)橫跨每個 RAID 陣列中的一個物理磁盤。也就

25、是說，將 EXTENTSIZE 設為條塊大小，而不是上一節(jié)推薦的條帶大小。在這樣的配置中，在連續(xù)預取期間，每個表空間容器采用單個盤區(qū)大小的 I/O 便不適用，因為它只能驅(qū)動文件系統(tǒng)所基于的 RAID 陣列中的一個物理磁盤。對于這些系統(tǒng)，如果想讓數(shù)據(jù)庫管理器生成多盤區(qū)大小的預取請求，并行地驅(qū)動用于每個 DB2 表空間容器的物理磁盤，就必須設置 DB2_PARALLEL_IO 。DB2_PARALLEL_IO 允許用戶顯式地指定每個容器下的物理磁盤數(shù)，以便為每個容器生成適當數(shù)量的預取請求。例如，如果每個表空間容器存在于一個由 RAID 5 4+1 陣列支持的文件系統(tǒng)上，那么下面是合適的 DB2_P

26、ARALLEL_ IO 設置： db2set DB2_PARALLEL_IO=*,5“* ”表示該設置適用于所有表空間。5 表示在每個容器下有 5 （4+1 ）個物理磁盤，每個物理磁盤都應該由一個單獨的預取程序所發(fā)出的單盤區(qū)大小的讀請求來驅(qū)動。以下算法將 DB2_PARALLEL_IO 設置考慮在內(nèi)：· 當 CREATE or ALTER TABLESPACE 語句上的 PREFETCHSIZE 選項設為 AUTOMATIC 時，計算每個表空間的預取大小。· 當 num_ioservers 配置參數(shù)設為 AUTOMATIC 時，計算 I/O 服務器或預取程序的數(shù)量。（請參閱

27、“不要手動調(diào)優(yōu) NUM_IOCLEANERS 、NUM_IOSERVERS 和 PREFETCHSIZE 配置參數(shù)”小節(jié)，獲得相關(guān)建議。）使用 NO FILE SYSTEM CACHING 子句NO FILE SYSTEM CACHING 子句支持直接或并發(fā) I/O ，其中任何一個都適合 DB2 數(shù)據(jù)庫系統(tǒng)所在的操作系統(tǒng)平臺。直接或并發(fā) I/O 有效地使 DB2 I/O 操作在文件系統(tǒng)上獲得接近原始設備的性能。在 DB2 Universal Database, Version 8.2 中，對 NO FILE SYSTEM CACHING 子句的支持已經(jīng)被添加到 CREATE TABLESPAC

28、E 和 ALTER TABLESPACE 語句中。從 Version 9.5 開始，對于那些支持直接或并發(fā) I/O 的文件系統(tǒng)，例如 JFS2 、GPFS 和 VxFS ，新創(chuàng)建的數(shù)據(jù)庫已默認如此。使用 DB2 自動化存儲讓條帶化無處不在DB2 自動化存儲（AS ）技術(shù)是為數(shù)據(jù)庫配置存儲的一種簡單而有效的方式。存儲通過 CREATE DATABASE 命令直接提供給數(shù)據(jù)庫，而非表空間。例如： DB2 CREATE DATABASE MYDB ON /data1, /data2, /data3 DBPATH ON /mydbpath這個例子命令創(chuàng)建一個數(shù)據(jù)庫，它有 3 個存儲路徑：data1 、

29、data2 和 data3 。每個路徑都是一個單獨的文件系統(tǒng)，每個文件系統(tǒng)都是通過專用的 LUN 創(chuàng)建的。（注意：除非另外指定，否則在使用 CREATE DATABASE 命令創(chuàng)建數(shù)據(jù)庫時將默認使用自動化存儲。）CREATE DATABASE 命令上的 DBPATH 參數(shù)被設為另一個單獨的文件系統(tǒng)（/mydbpath ），該文件系統(tǒng)是使用為 DB2 事務日志提供的 LUN 創(chuàng)建的。事務日志和 DB2 元數(shù)據(jù)都存放在這個文件系統(tǒng)上。DB2 數(shù)據(jù)庫系統(tǒng)創(chuàng)建的默認表空間（SYSCATSPACE 、USERSPACE1 和 TEMPSPACE1 ）各有 3 個控制器 對應 3 個存儲路徑。任何未顯式指

30、定容器而創(chuàng)建的新的表空間也是使用隨處條帶化的方法創(chuàng)建的。例如，考慮以下 DB2 語句： DB2 CREATE TABLESPACE MYTS使用 CREATE TABLESPACE 語句創(chuàng)建的表空間 MYTS 有 3 個容器，每個容器對應一個存儲路徑。雖然使用自動化存儲不妨礙在同一個數(shù)據(jù)庫中定義系統(tǒng)管理空間（SMS ）或數(shù)據(jù)庫管理空間（DMS ）的表空間或文件，但是自動化存儲通常會消除這方面的需要。由于 DB2 存儲管理器使用簡單的隨處條帶化方法，自動化存儲的最佳實踐是使用容量一致的存儲路徑或文件系統(tǒng)。這樣可確保并行性保持一致，不至于使某個存儲路徑過早地被填滿，而導致某些部分的表空間的條帶化寬度不同于其他表空間。當需要為數(shù)據(jù)庫增加空間時，應盡量均衡擴展所有已有的路徑。也就是說，等量地增加每個文件系統(tǒng)的容量。如果不能均衡擴展存儲路徑，那么使用 ALTER DATABASE 命令的 ADD STORAGE ON 子句增加一組新的（大小均等的）存儲路徑。這組新的存儲路徑應該與原有存儲路徑有相同的 I/O 功能。理想情況下，應該同時添加與之前定義的存儲路徑數(shù)量相同的存儲路徑。例如，為了給之前創(chuàng)建的數(shù)據(jù)庫 MYDB 增加空間，最佳選擇是等量增加文件系統(tǒng) /data1 、/data2 和 /data3 的容量。如果做不到，那么應該增加一組新的存儲路徑（文件系統(tǒng)