1、在 Microsoft SQL Server中的關(guān)系型數(shù)據(jù)倉庫分區(qū)策略SQL Server 技術(shù)性文章作者：Gandhi Swaminathan協(xié)作： Hao Chen, Rakesh Gujjula, Gang He技術(shù)審查： Wey Guy, Stuart Ozer, Arun Marathe, John Miller, Mike Ruthruff, Brian Goldstein發(fā)布日期： January 2005更新： Insert Date: MM YYYY適用于： SQL Server 2005摘要：分區(qū)，在Microsoft SQL Server中，便于對高可用關(guān)系型數(shù)據(jù)倉庫進行

2、有效的管理。本白皮書討論了在此環(huán)境中影響分區(qū)策略以及設(shè)計，實現(xiàn)，管理等需要考慮事項的幾個因素。我們推薦本文的讀者已經(jīng)閱讀并且理解以下的文章： 使用一個Microsoft SQL Server 2000數(shù)據(jù)倉庫中的分區(qū)- /library/default.asp?URL=/library/techart/PartitionsInDW.htm SQL Server 2000 步進的批量導(dǎo)入案例學習 - /technet/prodtechnol/sql/2000/maintain/incbulkload.m

3、spx Kimberly L. Tripp 所作的SQL Server 2005 分區(qū)表和索引 - /resources/Whitepapers/Partitioning%20in%20SQL%20Server%20Beta%20II.htm本白皮書關(guān)注的重點是關(guān)系型數(shù)據(jù)倉庫和表分區(qū)。它的目標讀者是： 通過使用Microsoft SQL Server中的分區(qū)視圖實現(xiàn)了分區(qū)的開發(fā)人員和數(shù)據(jù)庫管理員。這類讀者將會得益于SQL Server 2005中的分區(qū)優(yōu)勢以及關(guān)于滑動窗口實現(xiàn)和策略的部份。 在未來計劃使用分區(qū)的開發(fā)人員和數(shù)據(jù)庫管理員將會通過詳細閱讀

4、本白皮書而獲益非淺。數(shù)據(jù)庫和系統(tǒng)管理員將會得益于有關(guān)存儲域網(wǎng)絡(luò)管理以及優(yōu)化I/O利用策略的部份。版權(quán)該白皮書為初步文檔，可能會在所述軟件進行最后商業(yè)發(fā)布之前做完全修改。該文檔所含信息代表微軟公司在文檔出版時對所論及問題的當前看法。由于微軟必須對千變?nèi)f化的市場情況做出相應(yīng)反應(yīng)，因此本文檔不應(yīng)視為微軟的任何承諾，且微軟不保證所陳述任何信息在產(chǎn)品發(fā)布后的準確性。本白皮書僅供信息參考。微軟對本文件中的信息不做任何明示或默示保證。遵守所有適用的版權(quán)法律是用戶應(yīng)盡的責任。下述陳述不限制任何版權(quán)，在未獲得微軟公司明示書面許可的情況下，不得以任何目的復(fù)制本文檔任何部分或?qū)⑷魏尾糠直４婊蛞霗z索系統(tǒng)、亦不得以任

5、何形式（電子、機械、影印、錄制或其他方式）進行傳播。微軟在文件所述主題中擁有專利權(quán)、專利應(yīng)用程序、商標、版權(quán)或其他知識產(chǎn)權(quán)。除非在微軟的任何書面許可協(xié)議中明示規(guī)定，否則對本文檔的提供不得視為對任何專利權(quán)、商標、版權(quán)或其他知識產(chǎn)權(quán)許可的提供。除非特別聲明，本文中描述的示例公司、組織、產(chǎn)品、域名、e-mail地址、徽標、人物、地點以及事件均為虛構(gòu)的，不應(yīng)與任何實際的公司、組織、產(chǎn)品、域名、e-mail地址、徽標、人物、地點以及事件有任何的聯(lián)系。 2005微軟公司版權(quán)所有。Microsoft和ActiveX是微軟公司在美國和其他國家的注冊商標或商標。本文中實際公司和產(chǎn)品的名稱可能是其相應(yīng)所有者的商標

6、。內(nèi)容列表對一個關(guān)系型數(shù)據(jù)倉庫進行分區(qū)1關(guān)于關(guān)系型數(shù)據(jù)倉庫1分區(qū)的好處1在 SQL Server 7.0/2000中的分區(qū)技術(shù)1在SQL Server 2005中的分區(qū)技術(shù)2在SQL Server 2005中分區(qū)的優(yōu)勢2標識一個查詢計劃中的 Demand Parallelism3從SQL Server 2000的分區(qū)視圖遷移到 SQL Server 2005 分區(qū)表/索引4影響關(guān)系型數(shù)據(jù)倉庫分區(qū)的因素4數(shù)據(jù)量4數(shù)據(jù)導(dǎo)入4索引5數(shù)據(jù)老化5數(shù)據(jù)存檔5查詢性能5滑動窗口實現(xiàn)5交換分區(qū)的最佳實踐8將數(shù)據(jù)存儲到一個性價比高I/O子系統(tǒng)的技術(shù)9關(guān)系型數(shù)據(jù)倉庫的分區(qū)策略9策略 I 將一個分區(qū)綁定到它自己的文

7、件組9策略Strategy II 將兩個或更多分區(qū)綁定到同樣的文件組10哪個策略更好?10結(jié)論11附錄 A: 性能數(shù)值12批量插入性能12轉(zhuǎn)換性能12索引構(gòu)建性能13數(shù)據(jù)庫備份性能14老化數(shù)據(jù)到ATA 磁盤14附錄 B: 平臺列表14Microsoft 軟件14服務(wù)器平臺14存儲15主機總線適配卡15存儲管理軟件15附錄 C: 服務(wù)器體系結(jié)構(gòu)15附錄 D: EMC CLARiiON 存儲15拓樸16附錄 E: 存儲隔離17配置你的存儲18附錄 F: 腳本18對一個關(guān)系型數(shù)據(jù)倉庫進行分區(qū)以下的部份將會簡要的解釋關(guān)系型數(shù)據(jù)倉庫的概念，為關(guān)系型數(shù)據(jù)倉庫進行分區(qū)的好處，以及遷移到Microsoft S

8、QL Server 2005分區(qū)的好處。關(guān)于關(guān)系型數(shù)據(jù)倉庫關(guān)系型數(shù)據(jù)倉庫提供了一個廣泛的數(shù)據(jù)來源以及一個用來構(gòu)建業(yè)務(wù)智能（BI）解決方案的體系結(jié)構(gòu)。另外，關(guān)系型數(shù)據(jù)倉庫可以為報表應(yīng)用程序以及復(fù)雜且專用的SQL查詢所用。一個典型的關(guān)系型數(shù)據(jù)倉庫是由維度表以及事實表組成的。維度表通常會比事實表小一些并且其中提供了關(guān)于解釋事實的屬性的詳細信息。一個維度的例子是貨物，商店和時間。事實表提供了對商業(yè)記錄的描述，比如在所有商店中貨物銷售的信息。事實表通過最近收集到的數(shù)據(jù)進行不斷的更新。一個成功的關(guān)系型數(shù)據(jù)倉庫解決方案的實現(xiàn)包括細致而長期的規(guī)劃。以下列出了在構(gòu)建一個關(guān)系型數(shù)據(jù)倉庫時要考慮的要素： 數(shù)據(jù)量 數(shù)

9、據(jù)導(dǎo)入窗口 索引維護窗口 工作負載特征 數(shù)據(jù)老化策略 存檔和備份策略 硬件特征這個文檔后面的部份將會有對以上要素的詳細討論。 一個關(guān)系型數(shù)據(jù)倉庫在實現(xiàn)時可以采用分區(qū)的方法或者一個（巨大）事實表的方法。對于使用分區(qū)還是不分區(qū)方式的設(shè)計選擇主要依賴于前面列出的各個要素。關(guān)系型數(shù)據(jù)倉庫可以從數(shù)據(jù)分區(qū)中獲益。以下部份著重談到了分區(qū)為關(guān)系型數(shù)據(jù)倉庫帶來的好處。分區(qū)的好處當組織中的數(shù)據(jù)庫向上擴展并且包含了大量的數(shù)據(jù)時，非常關(guān)鍵的是保持其高可用性并同時適應(yīng)對小的數(shù)據(jù)庫維護窗口的需要。這些需求使得分區(qū)成為對于超大型數(shù)據(jù)庫而言的一個量身定制的技術(shù)。分區(qū)技術(shù)所強調(diào)的關(guān)鍵問題是通過將非常大的表分解成相對較小的分區(qū)從

10、而使諸如數(shù)據(jù)導(dǎo)入，老化以及存檔等重要任務(wù)的管理更易于進行。Microsoft SQL Server通過在SQL Server 7.0/2000中的分區(qū)視圖以及在SQL Server 2005中添加的對分區(qū)表的支持提供了分區(qū)技術(shù)。在 SQL Server 7.0/2000中的分區(qū)技術(shù)SQL Server 7.0通過分區(qū)視圖引入了對分區(qū)技術(shù)的支持。在SQL Server 2000中，這一功能進行了增強支持了可更新的分區(qū)視圖。當事實表可以被自然的分割或者根據(jù)數(shù)據(jù)范圍劃分成單獨的表時，對于關(guān)系型數(shù)據(jù)倉庫而言分區(qū)視圖技術(shù)是再合適不過的了。分區(qū)視圖的基表可以被UNION來表示成一個統(tǒng)一的數(shù)據(jù)集。分區(qū)視圖大

11、大降低成本應(yīng)用程序的復(fù)雜性，原因是物理實現(xiàn)被從應(yīng)用程序數(shù)據(jù)訪問方式中抽象了出來。在SQL Server 2000中，分區(qū)視圖可以被擴展到包括分布式分區(qū)視圖，從而啟用跨多個服務(wù)器/實例的數(shù)據(jù)庫聯(lián)合。有關(guān)分布式分區(qū)視圖的討論超出了本文的范圍。對此更詳細的討論，請參閱微軟開發(fā)人員網(wǎng)絡(luò)（MSDN）上的“分布式分區(qū)視圖”，地址是/sql/evaluation/features/distpart.asp!href(/sql/evaluation/features/distpart.asp).在SQL Server

12、2005中的分區(qū)技術(shù)在SQL Server 2005中通過使用表和索引的分區(qū)，可以降低在使用分區(qū)視圖管理非常大的數(shù)據(jù)庫時的復(fù)雜性。SQL Server 2005提供了用數(shù)據(jù)行作為最小的分區(qū)單位的水平范圍分區(qū)功能?？梢员环謪^(qū)的對象有： 基表 索引（聚簇和非聚簇的） 索引視圖范圍分區(qū)是通過自定義的數(shù)據(jù)范圍定義的表的分區(qū)。用戶通過分界值，一個使用文件組映射的分區(qū)架構(gòu)，以及映射到分區(qū)架構(gòu)的表來定義分區(qū)函數(shù)。一個分區(qū)函數(shù)決定了一個表或索引中特定的一行所屬于的分區(qū)。每個分區(qū)都是用一個通過一個分區(qū)架構(gòu)映射到某個存儲位置（文件組）的分區(qū)函數(shù)來定義的。對于在SQL Server 2005中實現(xiàn)分區(qū)的全面討論，請

13、參閱MSDN中的SQL Server 2005 分區(qū)表和索引。以下部份闡述了SQL Server 2005中分區(qū)功能的優(yōu)勢并提供了將分區(qū)表遷移到SQL Server 2005的策略。在SQL Server 2005中分區(qū)的優(yōu)勢在SQL Server 2005中的表和索引的分區(qū)功能通過將其分解為更易管理的分區(qū)大大方便了對超大型數(shù)據(jù)庫的管理。這一部份涉及了一些在針對關(guān)系型數(shù)據(jù)倉庫的使用中分區(qū)表相對于分區(qū)視圖的優(yōu)勢。管理一個使用分區(qū)視圖的缺點是當你使用它的時候，數(shù)據(jù)庫操作必須對單個的對象執(zhí)行而不是對視圖本身。舉個例子，如果一個現(xiàn)存的索引必須被刪除并且要創(chuàng)建一個新的索引，這些操作必須在每個相關(guān)的基表上

14、執(zhí)行。在SQL Server 2005中，諸如索引維護這樣的數(shù)據(jù)庫操作是對分區(qū)表本身而不是底層的相關(guān)分區(qū)上進行的，因而在管理索引過程中大大減輕了負擔。更好的Parallelism機制在SQL Server 2000中，操作是在單個表上執(zhí)行的并且數(shù)據(jù)在一個分區(qū)視圖的級別進行聚合。來自于基表中的行通過使用串聯(lián)運算符進行匯集并顯示視圖。然后再在結(jié)果集數(shù)據(jù)上執(zhí)行聚合。在SQL Server 2005中，對分區(qū)表執(zhí)行的查詢使用了一個被稱為demand parallelism的新的運算符。Demand parallelism受到系統(tǒng)資源和MAXDOP設(shè)置的影響。使用分區(qū)表的查詢將會比使用分區(qū)視圖進行的同樣

15、查詢更快的進行編譯。當使用分區(qū)視圖時查詢的編譯時間是與分區(qū)的數(shù)量成正比的，而使用分區(qū)表時查詢的編譯時間不會受到分區(qū)數(shù)量的影響。在某些情況下，對分區(qū)視圖進行查詢可能會更好一些。以下描述了這樣的情況： 當優(yōu)化器選擇使用demand parallelism時，parallelism的最小單位是一個分區(qū)。在SQL Server 2005中對一個分區(qū)表中的單個分區(qū)進行查詢的性能可能不太好，原因是parallelism的級數(shù)被限制到了1。同樣的查詢?nèi)绻麑σ粋€分區(qū)視圖進行可能會好一些，原因是在一個分區(qū)內(nèi)更好的parallelism 當分區(qū)的數(shù)量少于處理器的數(shù)量時使用分區(qū)視圖會更好一些，原因是通過parall

16、elism可以更好的使用處理器資源。當分區(qū)的數(shù)量大于處理器數(shù)量，而數(shù)據(jù)并不是在分區(qū)間平均分布時，對分區(qū)表查詢的性能可能仍舊不太好 當分區(qū)中的數(shù)據(jù)分布不均時使用對分區(qū)視圖的查詢也會更好一些標識一個查詢計劃中的 Demand Parallelism 下面是一個查詢計劃的示例，它是由一個加法聚合查詢產(chǎn)生的劃了紅圈的部份標明了在查詢計劃中出現(xiàn)的demand parallelism。嵌套循環(huán)運算符左邊的子demand parallelism是用分區(qū)ID來表示的。嵌套循環(huán)運算符右邊的子demand parallelism是用分區(qū)表自身來表示的。在這張圖表中，對于由左邊的子demand parallelis

17、m所返回的每一個分區(qū)ID，一個并行的索引查找運算符對來自對應(yīng)的分區(qū)中的行進行反復(fù)掃描。所有在嵌套循環(huán)運算符上進行的操作也受到由demand parallelism所建立的并行線程的數(shù)量的影響。左邊的子demand parallelism表示了僅當分區(qū)剪切生效時，也就是當查詢通過分區(qū)篩選結(jié)果時，被查詢所影響的分區(qū)ID，。圖表 1. 標識 demand parallelism從SQL Server 2000的分區(qū)視圖遷移到 SQL Server 2005 分區(qū)表/索引一個現(xiàn)存的基于單個巨表或者分區(qū)視圖的應(yīng)用程序可以被重構(gòu)或者遷移到一個基于分區(qū)的SQL Server 2005解決方案。要作出是重構(gòu)還

18、是遷移應(yīng)用程序的決定，必須詳細分析在性能，可管理性，以及可用性方面存在的需求。一個將SQL Server 2000的分區(qū)視圖遷移到SQL Server 2005分區(qū)表的簡單路徑將包括以下步驟： 創(chuàng)建一個分區(qū)函數(shù)和架構(gòu)以確定每個分區(qū)的分界點和物理存儲位置。分界點應(yīng)當和分區(qū)視圖的基表的差不多 在新建的分區(qū)架構(gòu)上創(chuàng)建一個分區(qū)表。該表應(yīng)當指定與分區(qū)視圖的基表同樣的物理結(jié)構(gòu)，包括索引 將分區(qū)視圖的每個基表交換為新建的分區(qū)事實表的一個分區(qū)。分區(qū)架構(gòu)所關(guān)聯(lián)的文件組必須與被交換進來的表所屬的文件組相匹配。另外，要遷移的表必須符合交換提示的要求。舉個例子，目標表不能是一個與架構(gòu)綁定的視圖的部件。關(guān)于交換提示的要

19、求列表，請參閱SQL Server 2005聯(lián)機叢書中的“使用分區(qū)交換有效的傳遞數(shù)據(jù)”影響關(guān)系型數(shù)據(jù)倉庫分區(qū)的因素對于一個分區(qū)的關(guān)系型數(shù)據(jù)倉庫的成功實現(xiàn)而言，包括了對數(shù)據(jù)庫增長和易管理性的規(guī)劃。接下來的部份闡述了影響關(guān)系型數(shù)據(jù)倉庫分區(qū)的因素以及滑動窗口實現(xiàn)的詳細信息。數(shù)據(jù)量當事實表的大小比較小時，分區(qū)只會添加更多的管理復(fù)雜性而不會帶來更多的價值。事實表的大小是基于應(yīng)用程序的特點并且由每一種實現(xiàn)方式所決定的。通常用戶需要事實表在他們實施分區(qū)之前至少有100 GB。數(shù)據(jù)導(dǎo)入數(shù)據(jù)導(dǎo)入是一個數(shù)據(jù)倉庫的核心部份。幾乎所有的數(shù)據(jù)倉庫都會周期性的處理最近收集的數(shù)據(jù)。是否成功的管理數(shù)據(jù)倉庫取決于批量導(dǎo)入進程的

20、效率以及導(dǎo)入過程中現(xiàn)有的數(shù)據(jù)能否繼續(xù)使用。在構(gòu)建你的事實表時有兩個選擇： 建立一個巨大的表，或者 使用分區(qū)的方式使用單個巨表這種方式與使用分區(qū)相比會導(dǎo)致較低的可用性，原因是在典型的關(guān)系型數(shù)據(jù)倉庫環(huán)境中批量導(dǎo)入操作是步進執(zhí)行的。例如，步進式的批量導(dǎo)入會從對目標表的鎖定中獲得巨大的好處。當使用單個表時，這樣做就會阻止所有其它的用戶在表導(dǎo)入的過程中訪問它。對于步進導(dǎo)入數(shù)據(jù)的最佳工作方式是使用一個規(guī)劃維護窗口。對于使用單個巨表這種方式中批量導(dǎo)入的全面討論請參閱在/technet/prodtechnol/sql/2000/maintain/incbulklo

21、ad.mspx 上的“SQL Server 2000步進批量導(dǎo)入案例學習”!href(/technet/prodtechnol/sql/2000/maintain/incbulkload.mspx)分區(qū)方式讓數(shù)據(jù)被批量導(dǎo)入到單個的分段表中，每一段都代表了一個確定的分區(qū)范圍。分段表隨后被添加到分區(qū)視圖當中或者被當作一個新的分區(qū)交換到分區(qū)表中。由于每一個分區(qū)邏輯上都是由一個單獨的分段表來代表的，因此步進的批量導(dǎo)入不會對任何針對現(xiàn)有數(shù)據(jù)的查詢造成可用性和性能上的影響。 一個典型的數(shù)據(jù)倉庫解決方案應(yīng)當包括在批量導(dǎo)入數(shù)據(jù)的同時進行數(shù)據(jù)轉(zhuǎn)換的功能。轉(zhuǎn)換包括對源

22、數(shù)據(jù)的清除和/或者聚合以產(chǎn)生目標庫。一個轉(zhuǎn)換典型情況下是通過使用象微軟系統(tǒng)集成服務(wù)這樣的工具來完成的。如果過程中不需要一個復(fù)雜的工作流，用戶可以選擇使用SELECT/INTO來完成轉(zhuǎn)換。 索引在把數(shù)據(jù)導(dǎo)入到一個關(guān)系型數(shù)據(jù)倉庫后，一般就要創(chuàng)建索引來為用戶查詢提供支持。在對關(guān)系型數(shù)據(jù)倉庫體系結(jié)構(gòu)造成影響的各個要素中創(chuàng)建和維護索引扮演了主要角色。在沒有索引時對事實表的查詢性能通常比較差。對于使用單個巨大事實表的情況，一個最佳的解決方案是刪除所有的索引，導(dǎo)入數(shù)據(jù)，然后重建索引。這種方法導(dǎo)致可用性的降低并且有一個不斷增長的維護窗口，當表的大小增長到一定程度時這種方法可能就不太現(xiàn)實了。 在SQL Serv

23、er 2000中當在基表上創(chuàng)建索引時，分區(qū)視圖有效的處理了這個問題。SQL Server 2005支持在單獨的分區(qū)上重建和重組索引，因而便于更好的管理分區(qū)索引。數(shù)據(jù)老化老化的數(shù)據(jù)被訪問的頻率比新的數(shù)據(jù)低一些。與日俱增的法律和規(guī)定需要業(yè)務(wù)保證老化的數(shù)據(jù)在線并能夠被立即訪問到。因而，在維護現(xiàn)有的數(shù)據(jù)的高可用性以及方便快速導(dǎo)入新的數(shù)據(jù)的同時有效的管理老化的數(shù)據(jù)對于一個企業(yè)是非常關(guān)鍵的。數(shù)據(jù)老化可以通過一個滑動窗口來有效的處理。如果數(shù)據(jù)被分區(qū)了，一個滑動窗口的實現(xiàn)就成為了可能。要查看更多的細節(jié)，請參閱本文后面的“滑動窗口實現(xiàn)”數(shù)據(jù)存檔對于一個幾T規(guī)模的數(shù)據(jù)倉庫的成功實現(xiàn)并不以構(gòu)建一個良好性能以及線性擴

24、展的系統(tǒng)而結(jié)束。它也依賴于對一個高度可用的系統(tǒng)的維護。如果數(shù)據(jù)被分區(qū)了，在SQL Server中的零散備份就可以實現(xiàn)。在SQL Server中的零散備份以及還原操作為分區(qū)的管理提供了更大的靈活性。零散備份備份意味著單個的分區(qū)，在被限制到它們自己的文件組時，可以被單獨的備份和還原而不會影響整個數(shù)據(jù)庫。在一個簡單恢復(fù)模型中為了零散備份可以工作文件組必須設(shè)置為只讀模式。在使用大容量日志恢復(fù)模型或者完全恢復(fù)模型的情況下，有必要備份事務(wù)日志-這樣做主要是為了成功的還原文件組。關(guān)于這些限制的更多細節(jié)，請參閱在SQL Server 聯(lián)機叢書中的“備份(Transact-SQL)”查詢性能專用的查詢是關(guān)系型數(shù)

25、據(jù)倉庫解決方案的一個主要部份。應(yīng)用程序的特點以及查詢所產(chǎn)生的結(jié)果的性質(zhì)對于關(guān)系型數(shù)據(jù)倉庫的分區(qū)有著極大的影響。例如，如果查詢中有一個對應(yīng)到分區(qū)鍵的篩選鍵，與對單個巨表進行的同樣查詢相比有更快的響應(yīng)速度。這是因為對分區(qū)的使用促進了并行操作的使用并且在查詢中的分區(qū)鍵意味著對數(shù)據(jù)的剪切更容易了?；瑒哟翱趯崿F(xiàn)滑動窗口是影響對關(guān)系型數(shù)據(jù)倉庫分區(qū)的一個關(guān)鍵要素之一因而值得用上一個單獨的部份對其具體實現(xiàn)的細節(jié)進行討論?；瑒哟翱诘膱鼍鞍▽⑿碌姆謪^(qū)滑動進去以及將老化的分區(qū)從分區(qū)表或者視圖滑動出來。當老化的數(shù)據(jù)存檔時新的數(shù)據(jù)就可以用來讓用戶查詢了。在滑動分區(qū)時的關(guān)鍵是最小化down機時間。老化的數(shù)據(jù)可以被存檔并

26、且可以通過還原相應(yīng)的備份在必要時取回，或者它也可以被移動到一個更低持久性，但更大I/O承受能力的始終可用以進行用戶查詢的子系統(tǒng)。下面的圖表展示了一個來自我們的測試場景的滑動窗口具體實現(xiàn)。在我們的測試場景中，從分布在全國的商店那里收集與消費者相關(guān)的銷售數(shù)據(jù)。數(shù)據(jù)被導(dǎo)入，純化，以及聚合來為商業(yè)決策提供支持。在我們的測試場景中，一個分區(qū)邏輯的代表了一周的有效數(shù)據(jù)。當前，八周的有效數(shù)據(jù)被標識為活動的?；顒拥臄?shù)據(jù)比老化的數(shù)據(jù)的查詢頻率高很多。當有新的數(shù)據(jù)進來，老化的數(shù)據(jù)就會移出。這兒有一條業(yè)務(wù)規(guī)則表明老化的數(shù)據(jù)應(yīng)當保持在線但是應(yīng)當存儲在一個經(jīng)濟有效的I/O子系統(tǒng)中。圖表 2. 滑動窗口方案在SQL Se

27、rver 2000中，滑動窗口可以使用分區(qū)視圖來實現(xiàn)。缺點是分區(qū)視圖必須被重新綁定來包括進在UNION視圖中的新生成的數(shù)據(jù)。重新綁定需要一個元數(shù)據(jù)鎖并且可能會被任何對現(xiàn)存視圖或者基表的訪問所阻塞。通過對使用Transact-SQL語句將分區(qū)交換進和交換出的支持SQL Server 2005提供了一個對滑動窗口方案的更佳實現(xiàn)。交換分區(qū)需要在分區(qū)表上放置一個架構(gòu)鎖。當沒有其它的進程在分區(qū)表上獲取了一個表級別的鎖時分區(qū)可以被交換進和交換出。如果分區(qū)被其它的進程使用或者如果其它的進程已經(jīng)在分區(qū)表上獲取了一個表級別的鎖，交換分區(qū)的構(gòu)建進程將會等待直到其它進程已經(jīng)釋放了鎖。分區(qū)交換是一個對元數(shù)據(jù)的操作因而

28、非?？焖?。下面的步驟可以用來在SQL Server 2005中使用分區(qū)表實現(xiàn)一個滑動窗口方案： 創(chuàng)建分區(qū)函數(shù)，架構(gòu)以及帶有適當分界點和關(guān)聯(lián)文件組的表。然后按照下面描述的四個步驟來執(zhí)行初始導(dǎo)入 創(chuàng)建代表單個分區(qū)的表 分別地填充表 向表中添加約束檢查來將數(shù)據(jù)值綁定到對應(yīng)的范圍上并且創(chuàng)建適當?shù)乃饕?。SQL Server 2005在創(chuàng)建分區(qū)表后創(chuàng)建初始索引時提供了一個額外的選項 將新近填充好的表交換進分區(qū)表的每一個分區(qū) 在初始導(dǎo)入之后，在一個表中任何新導(dǎo)入和交換進來的數(shù)據(jù)都不會成為分區(qū)表的一部份。一旦數(shù)據(jù)已經(jīng)就緒，在設(shè)置好適當?shù)姆纸琰c后表就可以被交換進分區(qū)表 類似的，老化數(shù)據(jù)可以被移動到更經(jīng)濟有效的I

29、/O子系統(tǒng)但是仍然在線并保持可用狀態(tài)接下來的部份涉及了一些針對分割分區(qū)表以及將分區(qū)交換進分區(qū)表的最佳實踐。交換分區(qū)的最佳實踐只有當目標表或者分區(qū)是空的時滑動窗口方案才工作。例如，如果一個分區(qū)“P”屬于分區(qū)表“PT”，它必須被交換出到表“T”，隨后目標表“T”必須被清空。類似的，當將表“T”交換進分區(qū)表“PT”的分區(qū)“P”，目標分區(qū)“P”應(yīng)當是空的。當跨分區(qū)的數(shù)據(jù)移動被最小化時，滑動窗口方案工作最佳。下面的代碼定義了分區(qū)函數(shù)和分區(qū)架構(gòu)。當在這個分區(qū)架構(gòu)上創(chuàng)建一個表時，分區(qū)表將會包括三個分區(qū)。第一個分區(qū)將會包含帶有 且 的鍵值。CREATE PARTITION FUNCTION SALES_MON

30、THLY_PARTITION_FUNCTION (INT)AS RANGE LEFT FOR VALUES ( , )GOCREATE PARTITION SCHEME SALES_MONTHLY_PARTITION_SCHEME AS PARTITION SALES_MONTHLY_PARTITION_FUNCTION ALL TO (PRIMARY)GOCREATE TABLE t(col1INT)ON SALES_MONTHLY_PARTITION_SCHEME(col1)GO當使用ALTER PARTITION函數(shù)的分割功能添加一個值為的新分界時，行會在相應(yīng)的分區(qū)間移動。ALTER P

31、ARTITION FUNCTION PARTITION_FUNCTION()SPLIT RANGE ()GO通過在原始的位置刪除行以及在新的位置添加行，行可以在分區(qū)間移動。和此次交換有關(guān)的分區(qū)在這一期間是不可訪問的。在這個例子中，新建的第二個分區(qū)將會擁有在鍵值范圍 且 且 且 =)在這一期間是無法訪問的。在我們的消費者場景中，新的數(shù)據(jù)是通過在活動的結(jié)尾處分割分區(qū)函數(shù)來添加的。老的數(shù)據(jù)是通過在老化的結(jié)尾處合并分區(qū)函數(shù)來刪除的。這種實現(xiàn)滑動窗口的方式消除了在交換進和交換出分區(qū)時的跨分區(qū)的數(shù)據(jù)移動，也就是說，新的數(shù)據(jù)被批量的導(dǎo)入到一個表中并且隨后通過在活動的結(jié)尾處分割它來交換進分區(qū)表，具體如下所示：

32、ALTER TABLE NEW_PARTITION SWITCH TO PARTITIONED_TABLE PARTITION $partition.WEEK_PARTITION_FUNCTION ()GO對于更多的信息，請參閱在SQL Server聯(lián)機叢書中的“設(shè)計分區(qū)來管理數(shù)據(jù)子集”將數(shù)據(jù)存儲到一個性價比高I/O子系統(tǒng)的技術(shù)一個滑動窗口的具體實現(xiàn)可以通過將老化的數(shù)據(jù)滑動到一個性價比高的I/O子系統(tǒng)中來進行擴展。例如，在我們的測試場景中，我們將老化的數(shù)據(jù)從一個高性能的I/O子系統(tǒng)滑出到了一個沒有同等高的性能但較為經(jīng)濟的I/O子系統(tǒng)中。特殊的滑動窗口實現(xiàn)可能無法通過在SQL Server中的備

33、份與還原操作來完成。有一些替換的方式可以實現(xiàn)這樣一個策略： 如果源文件是可用的，將數(shù)據(jù)導(dǎo)入到位于性價比高的I/O子系統(tǒng)的其它表中。重建索引。刪除老的分區(qū)并且將新近導(dǎo)入的表添加到分區(qū)表中。無論你的數(shù)據(jù)集的大小，down機時間將會是交換分區(qū)所需要的時間，可以忽略不計。 如果導(dǎo)入的過程中包含了轉(zhuǎn)換，在性價比高的I/O子系統(tǒng)上，通過使用一個SELECT/INTO查詢從老化的分區(qū)提取數(shù)據(jù)來創(chuàng)建新表并重建索引應(yīng)當更為有效。down機時間將會是交換分區(qū)所需要的時間。關(guān)系型數(shù)據(jù)倉庫的分區(qū)策略接下來的部份闡述了對你的關(guān)系型數(shù)據(jù)倉庫進行分區(qū)的兩個主要策略。該部份將會討論這些策略是如何作用于影響分區(qū)的要素的。策略

34、I 將一個分區(qū)綁定到它自己的文件組一個分區(qū)可以使用以下的步驟被邏輯的綁定到一個文件組： 創(chuàng)建帶有多個文件組的數(shù)據(jù)庫，每一個文件組將會邏輯的對應(yīng)一個分區(qū) 每個文件組中有一個文件。文件組可以包含一個或多個物理文件，并且這些文件可以在一個或多個邏輯卷/物理磁盤上創(chuàng)建 創(chuàng)建分區(qū)函數(shù)并將分界點映射到相應(yīng)的文件組，使用分區(qū)架構(gòu)來創(chuàng)建一個在文件組和分區(qū)之間的一一對應(yīng)的關(guān)系關(guān)于如何基于這個策略來實現(xiàn)分區(qū)的示例代碼請參閱附錄D圖表 3. 將分區(qū)映射到其自身的文件組策略Strategy II 將兩個或更多分區(qū)綁定到同樣的文件組第二個策略是將一個或者多個分區(qū)映射到同樣的文件組。文件組可以由一個（或者多個）分布在跨越

35、一個（或者多個）邏輯卷/物理磁盤的物理文件來組成。對于基于這個策略實現(xiàn)分區(qū)的示例代碼，請參閱附錄D圖表 4.將兩個或更多的分區(qū)映射到同一個文件組哪個策略更好?分區(qū)可以通過使用這兩個策略之一或者將兩個策略有效的結(jié)合到一起來實現(xiàn)。關(guān)于策略 I 和 策略 II可以參考下面的表格，其中解釋了這兩個策略對影響關(guān)系型數(shù)據(jù)倉庫分區(qū)因素的作用。策略 I策略 II數(shù)據(jù)導(dǎo)入 在SELECT/INTO SQL語句中不能明確的指定文件組。由于這一限制，在使用一個SELECT/INTO 語句時無法采用并行方式來完成初始轉(zhuǎn)換 步進的數(shù)據(jù)導(dǎo)入不會被分區(qū)策略所影響 當所有的分區(qū)映射到同一個文件組時轉(zhuǎn)換可以采用并行的方式完成

36、步進的數(shù)據(jù)導(dǎo)入不會被分區(qū)策略所影響備份/還原 在文件組和分區(qū)之間創(chuàng)建一個一一對應(yīng)的關(guān)系讓在分區(qū)級別的零散備份和還原操作得以進行 在備份數(shù)據(jù)庫之前確保分區(qū)被標記了只讀狀態(tài)。如果沒有，當還原數(shù)據(jù)庫時事務(wù)日志必須被前滾 如果所有的分區(qū)被映射到了同一個文件組，分區(qū)表作為一個整體可以使用單個的命令進行備份和還原 此策略在單個分區(qū)的粒度下不提供零散備份的靈活性查詢性能 如果文件組只包含一個文件，并且表會采用一個接一個的串行方式來進行填充，對這樣的對象的擴展盤區(qū)的分配是連續(xù)的。這意味著SQL Server對于一個連續(xù)的掃描可以提供多達256 KB的 I/O (4個擴展盤區(qū))速率 因為數(shù)據(jù)是連續(xù)的，因此對于大

37、量的連續(xù)掃描可以提供更好的工作負荷 如果文件組是由多個文件組成的，SQL Server使用按比例填充機制，這樣會導(dǎo)致擴展盤區(qū)出現(xiàn)碎片 類似的，在并行操作比如并行數(shù)據(jù)導(dǎo)入操作期間為對象/分區(qū)分配的擴展盤區(qū)無法保證是連續(xù)的 當為對象分配的擴展盤區(qū)不連續(xù)時，對于連續(xù)掃描SQL Server可以提供差不多64 KB的 I/O（1個擴展盤區(qū)）速率 因為數(shù)據(jù)分布在許多的物理磁盤上，因此它有助于在進行大量的并發(fā)隨機I/O操作時提供更好的工作負荷性能作為一個替換的方案，可以在啟動SQL Server時加上-E開關(guān)。當在啟動時指定了-E開關(guān)時，SQL Server可以分配4個而不是1個擴展盤區(qū)。因而-E開關(guān)讓S

38、QL Server可以提供多達256 KB 的I/O速率，即使存在因使用了按比例填充機制而產(chǎn)生的擴展盤區(qū)碎片結(jié)論本白皮書討論了影響分區(qū)的因素，以及對于設(shè)計分區(qū)可使用的兩個主要策略的正反兩面的對比。這里所提供的信息可能會對通過分區(qū)更有效的管理你的關(guān)系型數(shù)據(jù)倉庫有所幫助。有關(guān)的更多信息，請訪問:/sql/本文檔展示了SQL Server 2005的一些與關(guān)系型數(shù)據(jù)倉庫分區(qū)的相關(guān)特殊的功能。需要更多的信息，請參閱： SQL Server 2005聯(lián)機叢書提供了一些關(guān)于這個主題的有價值的信息，并且它可以作為使用SQL Server 2005實現(xiàn)數(shù)據(jù)分區(qū)的一

39、個不錯的起點。 CLARiiON CX600 Web站點: /products/systems/clariion_cx246.jsp附錄 A: 性能數(shù)值所有在這一部份展示的數(shù)值都是在我們使用SQL Server 2005的測試過程中得到的。該測試是在附錄B，C以及D中記錄的硬件平臺上進行的。批量插入性能在我們的測試中，我們可以在SQL Server 2005中使用剛剛超過一個小時的時間導(dǎo)入25億行。事實表的架構(gòu)中包含了九個整型列，一個日期類型列，以及一個字符型列。在這里展示的性能數(shù)值是在所有的線程以并行的方式執(zhí)行并且分區(qū)架構(gòu)基于策略I的環(huán)境下捕捉的。# 并行線

40、程執(zhí)行時間(在所有的線程執(zhí)行時)處理器使用率 (跨8個處理器)# 行插入批量拷貝吞吐量/秒批量拷貝行/秒磁盤吞吐量852 分鐘88 %44.77 MB/秒6,53,33941.17 MB/秒 跨 8 個LUNs on CLARiiON在這里展示的性能數(shù)值是在所有的線程以并行的方式執(zhí)行并且分區(qū)架構(gòu)基于策略II的環(huán)境下捕捉的。.#并行線程執(zhí)行時間(在所有的線程執(zhí)行時)處理器使用率 (跨8個處理器)#行插入批量拷貝吞吐量/秒批量拷貝行/秒磁盤吞吐量852分鐘92.625%2,550,835,65246.42 MB/秒44.29 MB/秒 跨 8 個LUNs on CLARiiON為數(shù)據(jù)倉庫分區(qū)所選擇

41、的策略并不影響批量導(dǎo)入的吞吐量。轉(zhuǎn)換性能在我們的測試中，批量導(dǎo)入的過程后面跟著一個轉(zhuǎn)換過程。轉(zhuǎn)換過程包括將源數(shù)據(jù)和維度表聯(lián)接在一起，其目的是為了使用提取的維度鍵值來填充目標倉庫。下面是一段在我們的測試場景中使用的示例代碼SELECT fact.fact_data_1, sdim.store_key, duct_key, tdim.time_keyINTO sales_transformedFROM sales fact, stores sdim, products pdim, time tdimWHERE fact.store_id = sdim.store_idAND con

42、vert(bigint, (fact.system + fact.generation + fact.vendor + duct) = ductid AND fact.weekid = tdim.weekid轉(zhuǎn)換查詢是連續(xù)運行的，一個查詢后面緊接著另一個，以致于在策略I中要保存前面的分區(qū)架構(gòu)設(shè)置# 并行線程執(zhí)行時間處理器使用率(跨1個處理器)# 被轉(zhuǎn)換的行 (每個轉(zhuǎn)換)磁盤讀吞吐量磁盤寫吞吐量1每個轉(zhuǎn)換差不多1小時13分鐘100%差不多3億行3.5 MB/秒 跨 1 LUN on CLARiiON(256 KB 讀)2.8 MB/秒 跨1 LUN on CLAR

43、iiON (128 KB 寫)以下是來自一個分區(qū)架構(gòu)的性能數(shù)值，它是基于策略II的并且所有的線程都是以并行方式執(zhí)行的。#并行線程執(zhí)行時間處理器使用率 (跨8個處理器)#被轉(zhuǎn)換的行(總計)磁盤讀吞吐量磁盤寫吞吐量81小時9分鐘99%2,478,765,08133.10 MB/秒 跨10 LUNs on CLARiiON26.66 MB/秒 跨10 LUNs on CLARiiON索引構(gòu)建性能在我們的測試中，我們可以用2個小時在跨越擁有25億行數(shù)據(jù)的八個分區(qū)的三個整型列（維度鍵）上創(chuàng)建一個聚簇索引。其中的SORT_IN_TEMPDB選項允許tempdb數(shù)據(jù)庫被用來對數(shù)據(jù)進行排序。在這個測試過程中使

44、用這個選項來隔離在索引建立過程中用來讀寫的物理磁盤。當sort_in_tempdb選項設(shè)置為on時，tempdb數(shù)據(jù)庫必須有足夠的剩余空間在離線的索引創(chuàng)建過程中用來放置整個的索引。當排序在一個用戶數(shù)據(jù)庫中完成時，每個文件組/分區(qū)需要有足夠的剩余空間來放置相應(yīng)的分區(qū)。在我們的消費者場景和設(shè)計中，每個分區(qū)邏輯的代表了一周的有效數(shù)據(jù)，這些數(shù)據(jù)帶有一個和在任何給定的分區(qū)中所有的行相同的鍵值。對于每個單獨的索引建立的parallelism的級數(shù)只能是1，因為distinct關(guān)鍵字值的數(shù)量是1。因而，在SQL Server 2005中我們在創(chuàng)建了分區(qū)表之后再創(chuàng)建起始索引的做法讓起始索引的建立更好的利用了可

45、用的處理器資源。# 并行線程執(zhí)行時間處理器使用率#行 82小時86%2,478,765,081數(shù)據(jù)庫備份性能在我們的測試中，我們花了一個小時多一點的時間來備份活動分區(qū)到4個RAID 3 LUNs on EMC CLARiiON存儲系統(tǒng)?；顒臃謪^(qū)分布在跨越8個LUNs的一個RAID 5 (4+1 10K RPM) EMC CLARiiON陣列上。目標設(shè)備是一個RAID 3 (4+1, 5K RPM ATA) CLARiiON陣列。執(zhí)行時間# 備份的頁 (8K) 備份/還原吞吐量/秒1小時20分鐘30,518,33050.15 MB/秒老化數(shù)據(jù)到ATA 磁盤老化數(shù)據(jù)到ATA磁盤包括使用SELECT

46、/INTO語句批量導(dǎo)入數(shù)據(jù)。以下是一段用來實現(xiàn)滑動窗口的代碼示例。ALTER DATABASE Customer ADD FILEGROUP ARCHIVE_1GOALTER DATABASE Customer ADD FILE (NAME = NARCHIVE_1, FILENAME = NF:ATARAID52ARCHIVE_PARTITION_1.NDF, SIZE = 100GB, FILEGROWTH = 0)TO FILEGROUP ARCHIVE_1GOALTER DATABASE Customer MODIFY FILEGROUP ARCHIVE_1 DEFAULTGOSELE

47、CT * INTO iri.Sales_129_ARCHIVEFROM VISF WHERE TIME_KEY = 129OPTION (MAXDOP 1)一個等價于在現(xiàn)存的分區(qū)表上的聚簇索引的聚簇索引必須在新的表上創(chuàng)建，以便能夠隨后交換進分區(qū)表。在我們的測試中，我們使用了SELECT/INTO來滑出第一個有2.79億行的老化分區(qū)到一個ATA磁盤陣列，整個過程用了不到20分鐘。在同樣的表上創(chuàng)建聚簇索引用了不到40分鐘。附錄 B: 平臺列表以下的硬件和軟件部件是用來進行本文中所描述的測試的：Microsoft 軟件Microsoft Windows Server 2003 數(shù)據(jù)中心版 Build

48、 3790Microsoft SQL Server 2005 Beta 2服務(wù)器平臺64-位 Unisys ES7000 Orion 13016 Itanium 2 1.30 GHz CPUs 帶有 3 MB 緩存64 GB 內(nèi)存存儲EMC Symmetrix 5.5- 96, 72 GB 10 KB RPM 磁盤 16 GB 讀寫緩存EMC CLARiiON FC4700- 155, 133.680 GB, 10 KB RPM磁盤16 GB讀寫緩存- 30, 344 GB, 5 KB RPM磁盤(ATA)主機總線適配卡8 Emulex LP9002L 2 GB/秒光纖通道主機總線適配卡所有的

49、適配卡映射到CLARiiON 存儲陣列，可以通過Powerpath 軟件實現(xiàn)負載均衡存儲管理軟件EMC Powerpath v 3.0.5附錄 C: 服務(wù)器體系結(jié)構(gòu)我們使用了一臺Unisys ES7000 Orion 130服務(wù)器來進行我們的測試。了解你的服務(wù)器的體系結(jié)構(gòu)對于確定你的系統(tǒng)的理論上的吞吐量是要素之一。例如，一個100 Mhz PCI總線能夠提供800 兆位/秒 的吞吐量。本附錄簡要的描述了ES7000 Orion的體系結(jié)構(gòu)。企業(yè)服務(wù)器ES7000 Orion 130是一個模塊化機架固定式系統(tǒng)，它基于一個Intel芯片組以及Intel Itanium 2處理器家族。在測試中使用的O

50、rion服務(wù)器配置了2個服務(wù)器模塊，16個處理器，以及64 GB內(nèi)存。每個服務(wù)器模塊帶有一個IOHM（輸入/輸出集線器模塊）。每個IOHM控制了一個由4個PCIAMs (PCI 適配器模塊)所組成的I/O子系統(tǒng)。每個PCIAM有兩個總線，每個提供2個PCI卡插槽。在每個總線上支持最高到100 Mhz的PCI卡。那些高亮的槽是當前配置的。在總線BUS 0-0上的槽2以及在PCIAM 0-0/IOHM-0上的總線BUS 0-1是為本地的SCSI磁盤以及網(wǎng)卡配置的，一共給我們留了16個槽。其中的8個使用Powerpath軟件映射到了CLARiiON存儲陣列。圖表 5.本場景中使用的CASSIN 服務(wù)

51、器的I/O配置附錄 D: EMC CLARiiON 存儲我們使用了一個CLARiiON CX600存儲陣列用來測試。本附錄概況的描述了使用的存儲陣列的配置信息。CLARiiON存儲陣列是由一系列的托盤和機架組成的。每個托盤可以放置多達15個磁盤。放在托盤中的大量磁盤被組織到一起來組成一個RAID組。從RAID組中生成的邏輯單元號碼（LUN）可以在Microsoft Windows操作系統(tǒng)中查看到。如果在將來需要添加更多的存儲設(shè)備，磁盤可以被安裝到存儲托盤并且組成RAID組，新創(chuàng)建的RAID組可以和任何現(xiàn)存的RAID組聯(lián)合在一起，形成一個可以在Windows操作系統(tǒng)中顯現(xiàn)的Meta -LUN。M

52、eta -LUN將會保持源LUN的LUN號。這些磁盤組成RAID組的形式不會影響性能，原因是CLARiiON存儲陣列可以實現(xiàn)跨托盤和物理磁盤的負載均衡。 在我們的測試中使用的EMC CLARiiON存儲陣列有著一個混合了RAID 1+0, RAID 5, 和 RAID 3的配置。RAID 1+0為數(shù)據(jù)庫日志文件所用而RAID 5為數(shù)據(jù)庫文件所用。RAID 3是用來備份和還原數(shù)據(jù)庫分區(qū)的。10KB RPM 物理磁盤是 133 GB 的而 5KB RPM 磁盤是344 GB我們的存儲配置包括5個RAID 1 + 0 LUNs。LUNs是一個由8個物理磁盤組成的RAID組所生成的。由于磁盤使用了條帶

53、和鏡像技術(shù)，因此每個LUNs都有大約500 GB (8*133.680 GB)/2)的存儲空間。RAID 1+0 LUNs中的兩個被用來放置數(shù)據(jù)庫的日志文件。12個RAID 5 LUNs用來存儲數(shù)據(jù)文件。5個RAID 5 LUNs是給tempdb數(shù)據(jù)庫用的。這些LUNs中的每一個都有大約500 GB的存儲空間。每個LUN源自一個RAID組。RAID 5的RAID組配置的相對于RAID 1 + 0的RAID組所包含的磁盤要少一些。RAID 5的RAID組是由5個133 GB磁盤組成的。下面描繪的是在一個CLARiiON存儲陣列中的RAID組和磁盤安排。來自于托盤2的3個物理磁盤和來自托盤1的兩個

54、物理磁盤組成了一個RAID組。下一個RAID組是通過交替來自每個托盤的磁盤的號來實現(xiàn)的。物理磁盤在托盤間交叉使用，作為一個最佳實踐，是為了在托盤級別出現(xiàn)了任何的失敗后系統(tǒng)仍可維持。圖表 6.CLARiiON RAID 3/5 以及RAID組配置拓樸在我們的測試中，使用了光纖通道技術(shù)并實現(xiàn)了一個標準的光纖交換式拓樸結(jié)構(gòu)。光纖通道是一個柔性的區(qū)域，在交換機級別使用了全世界通用的名稱光纖主機總線適配器(HBAs)。在這個測試場景中LUNs都被蓋了起來，只讓主機服務(wù)器可以看到存儲控制器。圖表7描述了在HBA和存儲設(shè)備端口以及LUNs間的映射。由于在我們的測試場景中，邏輯卷直接映射到了單個的LUN，因此

55、圖表也可被看作是到邏輯卷的映射EMCs Powerpath（多路徑軟件）是用來在所有基于CLARiiON存儲陣列的LUN間實現(xiàn)I/O負載均衡的。8個Emulex HBAs分成了區(qū)域來查看所有在CLARiiON存儲陣列上的LUNS。有關(guān)安裝Emulex HBAs with EMC storage的全部的詳細信息，請訪問： /ts/docoem/framemc.htm!href(/ts/docoem/framemc.htm).圖表 7.HBA-存儲端口-卷映射附錄 E: 存儲隔離在存儲域網(wǎng)絡(luò)環(huán)境中存儲隔離扮演了一個重要

56、的角色，特別是當數(shù)據(jù)在一個或者幾個應(yīng)用程序之間共享時。本附錄著重談到了在對你的關(guān)系型數(shù)據(jù)倉庫進行分區(qū)時對存儲隔離的一些需要考慮的事項。在這個附錄中的例子沿用了在我們的測試一開始就使用的EMC Symmetrix存儲陣列可以創(chuàng)建來自于多個物理磁盤的邏輯卷。類似的，多個邏輯卷也可以創(chuàng)建在同一個物理磁盤上。并且在某些情況下，多個邏輯卷可以在一組物理磁盤上創(chuàng)建。這種用法在存儲域網(wǎng)絡(luò)中是司空見慣的。在EMC Symmetrix中，物理磁盤被邏輯的分成了hyper卷。來自于多個物理磁盤的hyper卷可以成組創(chuàng)建一個Meta卷。Meta卷可以成組創(chuàng)建一個邏輯卷。在下面的圖表中，數(shù)字1到32代表了單個的物理磁盤。每個物理磁盤被分成了8 個9-GB 的hyper卷。Hyper卷1.1 到