摘要：本文介紹如何使用分區來改善 SQL Server 2000 Enterprise Edition 中數據倉庫的可管理性、查詢性能和加載速度，並討論關系型數據庫和分析服務多維數據集中的矢量架構的水平分區。
概述 本文討論數據倉庫中數據分區的作用。關系型數據倉庫和分析服務多維數據集都支持數據分區。分區的邏輯概念在 Microsoft® SQL Server™ 的兩個引擎中是相同的：通過鍵（例如日期）對數據進行水平分區。在關系型數據庫中，分區是通過創建單獨的物理表（例如為每個月的數據創建一個表）並且定義一個成員表的聯合視圖來實現的。與此類似，SQL Server Enterprise Edition 中的分析服務支持顯式的多維數據集分區。在關系型數據庫和聯機分析處理 (OLAP) 引擎中，物理存儲的復雜性對於分析用戶是不可見的。
數據倉庫分區的優點： 大大縮短查詢時間。
減少加載時間，改善數據庫的可維護性。
解決從活動數據庫中刪除舊數據時出現的數據修剪問題。
該技術需要創建比非分區系統更復雜的數據分階段應用程序。本文介紹設計、實現和維護水平分區數據倉庫的最佳方法。
因為有效的分區計劃可以極大地改善查詢性能，所以我們極力建議您對大型分析服務系統進行分區。盡管對於某些特定的數據倉庫維護問題，對關系型數據倉庫進行分區是有效的解決方案，但通常不推薦您這樣做。
在 SQL Server 2000 關系型數據倉庫中使用分區
分區視圖聯接來自一組成員的水平分區數據，使數據看起來象來自同一張表。SQL Server 2000 區分本地分區視圖和分布式分區視圖。在本地分區視圖中，所有相關表和視圖駐留在 SQL Server 的同一實例上。在分布式分區視圖中，相關表中至少有一張表駐留在其他某個（遠程）服務器上。建議您不要將分布式分區視圖用於數據倉庫應用程序。
矢量數據倉庫圍繞事實（標量）和矢量構建，從物理上通常表示為星形架構和雪花形架構，極少有同時包含事實和矢量的完全非正交化的平面表。由於矢量架構是最常見的關系型數據倉庫結構，本文集中討論這類架構的分區。下面的建議也適用於其他通用數據倉庫架構。
分區的優點 數據修剪
許多數據倉庫管理員會定期將陳舊的數據歸檔。例如，一個單擊流數據倉庫可能只將詳細數據聯機保留三至四個月。其他常見的規則可能是聯機保留 13 個月、37 個月或 10 年，當舊數據不在活動窗口中時就歸檔並從數據庫中刪除。這種滾動窗口結構是大數據倉庫通常采取的做法。
在沒有分區表的情況下，從數據庫中刪除舊數據的進程需要一個很大的 DELETE 語句，例如：
DELETE FROM fact_table
WHERE date_key < 19990101
執行該語句開銷會非常大，可能比同一張表的加載進程需要更多的時間。相反，對於分區表，管理員重新定義 UNION ALL 視圖以排除最舊的表，然後將該表從數據庫中刪除（假設已確保備份該表），這個過程幾乎可以在瞬間完成。
後面我們會討論到，維護分區表的費用也很高。如果數據修剪是采用分區的唯一原因，設計者應考慮以數據分解的方式從未分區的表中刪除舊數據。在低優先級進程上連續運行一個每次刪除 1000 行（用“set rowcount 1000”命令）的腳本，直至刪除所有希望刪除的數據。該技術可在大系統上有效運用，比創建必要的分區管理系統更為直接。根據加載量和系統使用狀況，該技術適合於某些系統，並應該考慮在系統上進行基准測試。
加載速度 加載數據最快的方法是將數據加載至空表或沒有索引的表。通過加載至較小的分區表，漸變加載進程的效率將大大提高。
可維護性 一旦已建成支持分區的數據倉庫分階段應用程序，整個系統將變得容易維護。維護活動（包括加載數據、備份和還原表）可以並行地執行，這樣可以極大地改善性能。漸變填充下行數據流多維數據集的進程可以被加速和簡化。
查詢速度 查詢速度不應該作為對數據倉庫關系型數據庫進行分區的理由。對於分區和未分區的事實表，查詢性能都差不多。在正確設計的分區數據庫中，關系引擎僅在查詢計劃中包括解析查詢所需的相關分區。例如，如果數據庫按月分區，查詢條件為 2000 年 1 月，則查詢計劃僅包括 2000 年 1 月的分區。結果查詢將對分區表正確執行，與在分區鍵上帶有簇索引的已索引合並表上執行的大體相同。
分區的缺點 復雜性 分區的主要缺點是需要管理員創建應用程序來管理分區。
