在SQL Server 2000 資料倉儲中使用分區

分區視圖聯結來自一群組成員的水平資料分割資料，使資料看起來象來自同一張表。SQL Server 2000 區分本機資料分割檢視和分散式資料分割檢視。在本機資料分割檢視中，所有相關表和視圖駐留在 SQL Server 的同一執行個體上。在分散式資料分割檢視中，相關表中至少有一張表駐留在其他某個（遠程）伺服器上。建議您不要將分散式資料分割檢視用於資料倉儲應用程式。

向量資料倉儲圍繞事實（標量）和向量構建，從物理上通常表示為星形架構和雪花形架構，極少有同時包含事實和向量的完全非正交化的平面表。由於向量架構是最常見的關係型資料倉儲結構，本文集中討論這類架構的分區。下面的建議也適用於其他通用資料倉儲架構。

分區的優點

資料修剪：

許多資料倉儲管理員會定期將陳舊的資料歸檔。例如，一個單擊流資料倉儲可能只將詳細資料聯機保留三至四個月。其他常見的規則可能是聯機保留 13 個月、37 個月或 10 年，當舊資料不在使用中視窗中時就歸檔並從資料庫中刪除。這種滾動視窗結構是大資料倉儲通常採取的做法。

在沒有分區表的情況下，從資料庫中刪除舊資料的進程需要一個很大的 DELETE 語句，例如：

DELETE FROM fact_tableWHERE date_key < 19990101

執行該語句開銷會非常大，可能比同一張表的載入進程需要更多的時間。相反，對於分區表，管理員重新定義 UNION ALL 視圖以排除最舊的表，然後將該表從資料庫中刪除（假設已確保備份該表），這個過程幾乎可以在瞬間完成。

後面我們會討論到，維護分區表的費用也很高。如果資料修剪是採用分區的唯一原因，設計者應考慮以資料分解的方式從未分區的表中刪除舊資料。在低優先順序進程上連續運行一個每次刪除 1000 行（用“set rowcount 1000”命令）的指令碼，直至刪除所有希望刪除的資料。該技術可在大系統上有效運用，比建立必要的分區管理系統更為直接。根據載入量和系統使用狀況，該技術適合於某些系統，並應該考慮在系統上進行基準測試。

載入速度：

載入資料最快的方法是將資料載入至空表或沒有索引的表。通過載入至較小的分區表，漸層載入進程的效率將大大提高。

可維護性：

一旦已建成支援分區的資料倉儲分階段應用程式，整個系統將變得容易維護。維護活動（包括載入資料、備份與還原表）可以並行地執行，這樣可以極大地改善效能。漸層填充下行資料流Cube的進程可以被加速和簡化。

查詢速度：

查詢速度不應該作為對資料倉儲關係型資料庫進行分區的理由。對於分區和未分區的事實表，查詢效能都差不多。在正確設計的分區資料庫中，關聯式引擎僅在查詢計劃中包括解析查詢所需的相關分區。例如，如果資料庫按月分區，查詢條件為 2000 年 1 月，則查詢計劃僅包括 2000 年 1 月的分區。結果查詢將對分區表正確執行，與在分區鍵上帶有簇索引的已索引合并表上執行的大體相同。

分區的缺點

複雜性:

分區的主要缺點是需要管理員建立應用程式來管理分區。在尚未設計、測試和試運行應用程式來管理分區之前，將在關係型資料庫中使用水平資料分割的資料倉儲投入正式運行是不恰當的。本文的目的之一就是討論與分區管理應用程式有關的問題和設計決策。

查詢設計約束:

要獲得最佳的查詢效能，所有的查詢都應將條件直接放在事實表中的篩選鍵上。將約束放在第二張表（例如以日期為向量的表）的查詢將包括所有分區。

設計時要考慮的因素:

向量資料倉儲圍繞事實（標量）和向量構建，從物理上通常表示為星形架構和雪花形架構，極少有同時包含事實和向量的完全非正交化的平面表。典型情況下，向量資料倉儲的管理員僅對事實表進行分區；對向量表進行分區幾乎沒有什麼好處。在某些情況下，對包含多於一千萬個成員的大型向量表進行分區會有些好處。也可以對非向量關係型資料倉儲進行分區，本文中的一般觀點仍然適用。

只有充分考慮系統體繫結構和設計目標，才能制訂有效分區計劃。即使使用相同的架構設計，僅用於填充服務分析Cube的關係型資料倉儲可能採用一個不同於分析員直接查詢的資料倉儲的分區結構。帶有滾動視窗的系統必須按時間分區，其他系統則不一定。

如果資料倉儲包括分析服務Cube，Microsoft 建議關係型資料倉儲和分析服務資料庫中的分區應該為並行結構。維護應用程式被簡化了：應用程式在關係型資料庫中建立新表的同時建立一個新Cube分區。管理員僅需要掌握一種分區策略。不過，一個應用程式也可能有充分的理由對兩個資料庫以不同方式進行分區，唯一降低的將是資料庫維護應用程式的複雜性。

分區設計概述

SQL Server 資料庫中的分區表可以使用可更新或可查詢（不可更新）的分區視圖。在這兩種情況下，表分區都是由每個分區都包含正確資料的 CHECK 條件約束來建立的。一個可更新的分區視圖支援對視圖進行 INSERT (或 UPDATE 或 DELETE）操作，並將操作推入至正確的基礎資料表。這很有益處，但資料倉儲應用程式通常需要進行批量載入，而這是無法通過視圖執行的。下表總結了可更新和可查詢分區視圖的要求、優點和缺點。

Microsoft 建議的做法是定義主鍵，並將事實表設計為本地（單個伺服器上）的分區聯合視圖。大多數情況下，該定義會產生可更新的分區視圖，但資料倉儲維護應用程式應設計為直接將大多數資料批量載入至成員表（而不是通過視圖進行）。

1 2 3 4 下一頁

【內容導航】
第1頁：在SQL Server 2000 資料倉儲中使用分區	第2頁：在SQL Server 2000 資料倉儲中使用分區
第3頁：在SQL Server 2000 資料倉儲中使用分區	第4頁：在SQL Server 2000 資料倉儲中使用分區