SQL Server 2008-數據倉庫查詢性能

SQL Server 2008

數據倉庫查詢性能

Sunil Agarwal and Torsten Grabs and Dr. Joachim Hammer

 

概覽:

• 星型聯接查詢優化
• 分區表並行處理
• ROW 和 PAGE 壓縮
• 分區對齊的索引視圖

較前期同類產品相比，SQL Server 2008 將提供功能更爲強大的關係數據倉庫，但是您可能仍希望瞭解如何充分利用這項新技術來構建性能良好的數據倉庫，以便對數十億行的數據進行決策支持查詢。或者您可能希望瞭解哪些功能將有助於您獲取針對決策支持查詢和報告的最佳查詢性能，或者該新版本的 SQL Server® 可實際帶來哪種性能改進。

越接近實際產品發佈，越會產生許多問題。我們在此深入探討 SQL Server 2008 中一些與性能相關的最重要數據倉庫功能，希望能對您有所裨益。

邏輯數據庫設計：維度建模

事務性業務線應用程序通常使用規範化數據庫架構。關係數據倉庫的邏輯數據庫架構設計不太注重規範化。現在的許多關係數據倉庫設計都使用維度建模方法，這種方法的流行得益於 Ralph Kimball 和 Margy Ross 合著的《The Data Warehouse Toolkit:The Complete Guide to Dimensional Modeling》。

如果經常與數據倉庫打交道，您可能已經熟悉關係數據倉庫的常見架構模式（如星型架構和雪花型架構）。維度建模將維度表與事實表區分開來。維度表存放主數據（如產品、客戶、商店或國家），而事實表則存儲事務性數據（如銷售、訂單、採購或利潤）。

維度表和事實表是通過主鍵 (PK)/外鍵 (FK) 關係鏈接在一起的。您會發現許多數據倉庫並未強行要求將 FK 約束作爲降低存儲要求的方法。這就節省了基礎索引的存儲開銷，降低了事實表的維護成本。數據倉庫中的維度表通常非常的小 — 一般最少幾千行，最多幾百萬行。事實表則非常大，存放着上億到十幾億行。因此，事實表的存儲要求是邏輯設計的真正重點。

在確定應從維度表中選擇哪個鍵來維護事實表/維度表關係時，這一大小因素也在考慮之內。基於維度業務鍵的組合鍵（表示維度所代表實體的實際標識符）通常包含多個列。請注意，對於事實表中的對應外鍵而言，這是個問題，因爲會對每個事實錶行重複這一多列組合鍵。

爲此，一種常見的方法是使用小的代理鍵在事實表及其維度之間建立關係。代理鍵是一個整數型標識列，用作維度表的虛擬主鍵。事實表引用更小的代理鍵後，大型事實表的存儲要求得以顯著降低。圖 1 說明了使用維度表和代理鍵型事實表的維度建模數據倉庫架構。

Figure 1 包含一個事實表和兩個維度表的星型架構示例 (單擊該圖像獲得較大視圖)

雪花型架構設計將一個或多個維度散佈到多個級別（例如，某個客戶維度的客戶、國家和地區），從而規範化數據中存在過度冗餘的大型維度。各級別由單個表代表，從而使該架構呈雪花狀。而星型架構設計則不將其任何維度散佈到多個表內。星型架構形狀象星星，其中維度表圍繞四周，中心是事實表。

通過使用維度建模的星型架構或雪花型架構，決策支持查詢採用以下典型模式：查詢從事實表選擇多個感興趣的度量、通過代理鍵聯接事實行和一個或多個維度、針對維度表的業務列應用篩選謂詞、按一個或多個業務列分組，並統計在一段時間內從事實表檢索的度量。以下即是該模式的示例，它有時也被稱爲星型聯接查詢：

select ProductAlternateKey,
CalendarYear,sum(SalesAmount)
from FactInternetSales Fact
     join DimTime 
on Fact.OrderDateKey = TimeKey
     join DimProduct 
on DimProduct.ProductKey =
   Fact.ProductKey
where CalendarYear between 2003 and 2004
      and ProductAlternateKey like 'BK%'
group by ProductAlternateKey,CalendarYear

物理設計

關係數據倉庫中的許多 SQL 查詢都遵循星型聯接查詢結構。然而，決策支持查詢通常應時而變，因爲決策者們總是希望通過新方法來更好地瞭解其基礎業務數據。這就是數據倉庫要面對大量臨時查詢的原因。這也使得決策支持查詢和維度建模數據倉庫架構的物理設計富有挑戰性。

通過使用 SQL Server，數據倉庫設計人員通常首先建立一個藍圖或物理設計，它可根據工作負載的變化進行精細調整。可根據您數據倉庫環境的實際情況自由使用或更改該藍圖。如果是這樣，請謹記數據庫物理設計的最佳實踐，如索引更新維護所引起的性能影響以及索引的存儲要求。

事實表

藍圖設計旨在預計典型的星型查詢形狀並構建事實表的索引。事實表的聚集索引將多個維度代理鍵列（外鍵列）作爲索引鍵。最常用的列應出現在索引鍵列表中。您可能希望確認它確實爲工作負載中最常執行的查詢提供了一個不錯的訪問路徑。

此外，藍圖爲事實表中的每個維度代理（外鍵）列創建了一個單列非聚集索引。從而爲某一維度極具選擇性的查詢提供了一個高效訪問路徑。

聚集索引的目標是爲提高工作負載中大部分查詢的性能。非聚集索引組的目標是爲特定客戶或產品檢索事實表度量的查詢。這些非聚集索引可幫您提高效率，例如，您不必掃描事實表來檢索單個客戶的銷售數據。

維度表

在對維度表應用藍圖設計時，需爲每個維度表創建索引。它們包括針對維度代理鍵列的非聚集主鍵約束索引，以及針對維度實體業務鍵列的聚集索引。對於大型維度表，還應考慮增加針對高選擇性謂詞中常用列的非聚集索引。

聚集索引在數據倉庫維護期間可提高提取、轉換和加載 (ETL) 效率，而維護對於時間要求往往很嚴格。例如，通過緩慢地更改維度，現有行得到適當更新，同時尚未出現在維度中的行則附加到維度表。爲成功達到目標，該訪問模式要求在 ETL 期間維度表的查詢和更新一切順利。

要對利用 SQL Server 構建的關係數據倉庫進行物理設計，我們提到的藍圖設計是個不錯的起點。根據該典型關係數據倉庫設置，我們可研究 SQL Server 2008 中包含的重要新功能。

星型聯接查詢優化

處理事實表通常是在維度建模關係數據倉庫中執行星型聯接查詢時最大的開銷。這一點顯而易見，因爲即使是高選擇性的查詢，從事實表檢索的行數都遠比從任何維度表檢索出的要多得多。因此，針對事實表使用最好的訪問路徑對於實現良好的查詢性能而言至關重要。

通過使用 SQL Server，查詢優化器可自動從一組備選方案中選擇開銷最低的訪問路徑。在數據倉庫環境中，主要目標是確保查詢優化器爲星型聯接查詢的執行計劃選擇最佳的備選訪問途徑。SQL Server 的查詢優化器中使用多種功能自動提供性能良好的星型查詢執行計劃。

可將星型聯接查詢視爲分成三個不同的類別（如圖 2 所示）。這幾大類還有助於 SQL Server 引擎找出適用於這些查詢的正確計劃。SQL Server 所依據的主要概念是這些查詢相對事實表的選擇性。查詢從事實表提取的行越少，越具選擇性。事實表檢索行的百分比用作這些查詢類的直觀區分標準。這些百分比代表來自典型客戶部署的值，但它們並非用於生成訪問路徑定義的嚴格分界線。

Figure 2 星型聯接查詢的選擇性範圍 (單擊該圖像獲得較大視圖)

第一類爲高選擇性查詢，最多處理事實表中 10% 的行。第二類爲中等選擇性，所包含的查詢處理事實錶行的 10% 到 75% 。第三類是低選擇性查詢，在事實表中處理的行超過 75%。圖中的方框還着重指出了每個選擇性類別中的基本查詢執行計劃選項。

基於選擇性的計劃選項

由於高選擇性星型查詢檢索的事實錶行通常不超過 10%，因此這些查詢可隨機訪問事實表。所以，該類的查詢計劃主要依賴於嵌套循環聯接以及對事實表的（非聚集）索引搜索和書籤查詢。由於它們對事實表執行隨機 I/O，因此如果需要檢索大部分事實表，可通過連續 I/O 獲取更好的性能。由於從事實表檢索的行數超過了一定數量，所以需要另一種查詢計劃。

由於中等選擇性的星型查詢會處理事實表中相當多的行，哈希聯接和事實表掃描或事實表範圍掃描通常是對事實表的首選訪問路徑。SQL Server 使用位圖篩選器來改善這些哈希聯接的性能。

圖 3 顯示了 SQL Server 如何使用這些位圖篩選器來改善星型聯接查詢執行期間的聯接性能。該圖顯示了針對 Product 和 Time 兩個維度表的一個查詢計劃，這兩個表通過代理鍵與事實表聯接。查詢針對兩個維度表使用篩選謂詞（如 WHERE 子句），以便只能有一行符合所有維度。兩個聯接運算符旁邊的小紅表格是這一特徵的指示符。

Figure 3 減少了聯接的星型聯接查詢計劃 (單擊該圖像獲得較大視圖)

每個聯接的聯接實施都是哈希聯接，它允許 SQL Server 從維度表將有關合格行的信息提取到兩個維度表的聯接減少信息中。圖中的綠色方框代表聯接減少信息數據結構。從底層維度表取得數據後，SQL Server 會在查詢執行期間自動把這些數據結構移到處理事實表的運算符（如表掃描）。該運算符使用有關維度錶行的信息來除去不滿足維度聯接條件的事實錶行。

從事實表檢索行後，SQL Server 在查詢處理期間的前期就會剔除這些事實錶行。這樣，在查詢計劃的後續運算符中無需再處理已剔除的行，從而可節省 CPU 甚至磁盤 I/O 的開銷。SQL Server 使用位圖表示來有效表達查詢執行期間的聯接減少信息數據結構。

星型聯接優化管道

優化過程使用標準的試探法來實現聯接查詢優化，以生成最初的一組查詢執行計劃備選方案。然後調用特殊的擴展項來生成其他查詢計劃備選方案。

對於數據倉庫，擴展項會檢測星型架構、雪花型架構以及星型查詢模式，並評估查詢相對事實表的選擇性。如果架構和查詢形式與模式匹配，SQL Server 會自動向計劃空間添加更多的查詢計劃，然後基於開銷的優化會對其進行處理以選擇最有前景的查詢執行計劃。

在查詢執行期間，SQL Server 還會監視聯接減少在運行時的實際選擇性。如果選擇性發生變化，SQL Server 會動態重新排列聯接減少信息數據結構，以便首先應用具有最大選擇性的計劃。

星型聯接試探法

數據倉庫的許多物理設計均遵循星型架構，但並不完全指定事實表和維度表之間的關係（例如之前提到的外鍵約束）。如果缺少明確指定的外鍵約束，SQL Server 必須依賴試探法來檢測星型架構查詢模式。可使用以下試探法來檢測星型聯接查詢模式：

1. 參與 n 元聯接的最大表被視爲是事實表。對於事實表的最小大小還有一些限制。例如，如果即使是最大的表也並未超過指定的大小，則不將 n 元聯接視爲星型聯接。
2. 星型聯接查詢中二元聯接的所有聯接條件必須爲單列等式謂詞。聯接必須爲內部聯接。儘管可能聽起來比較具有限制性，但是它涉及典型星型架構中使用代理鍵的事實表和維度表之間的絕大多數聯接。如果聯接擁有更復雜的聯接條件且不符合以上所述模式，則將從星型聯接排除該聯接。例如，如果其中兩個聯接具有更復雜的聯接謂詞，五路聯接可生成三路星型聯接（其他兩個聯接以後再用）。

請注意，存在試探法規則。在實際情況中，很少會讓試探法將維度表選作事實表。它會影響計劃選擇，但不會影響所選計劃的正確性。然後，按選擇性降序排列星型聯接中的二元聯接。本文中聯接選擇性定義爲事實表的輸入基數與聯接的結果基數的比率 — 聯接選擇性表示具體維度減少了多少事實表基數。通常，我們希望首先考慮具有更高選擇性的聯接。

如果結果查詢計劃的估計查詢花銷適合，SQL Server 中的查詢處理器會針對符合星型號聯接模式和上述條件的查詢自動應用優化。因此，您無需更改應用程序即可受益於這一顯著的性能改進。但要注意，某些星型聯接優化（如聯接減少）只有 SQL Server Enterprise Edition 才提供。

星型聯接性能結果

在開發 SQL Server 2008 中的星型聯接優化時，我們根據基準和實際客戶工作負載進行了大量性能研究。其中三種工作負載產生的結果頗具價值。

Microsoft 銷售組織數據倉庫 該工作負載跟蹤用於 Microsoft 銷售組織內部決策支持的數據倉庫的性能。我們列出了一個示例快照，其中的數據庫約爲 750GB（包括索引）。在此工作負載中，許多查詢的聯接數都大於 10，因此處理起來有一定難度。

零售客戶 這組試驗針對零售行業中的數據倉庫客戶（包括常規店鋪和在線展示）。客戶的特點是維度建模的雪花型架構和規範的星型聯接查詢。我們使用約 100GB 的原始數據來填充試驗用倉庫快照。

決策支持工作負載 這組試驗調查針對 100GB 維度建模數據庫的決策支持工作負載的性能。圖 4 顯示這三個工作負載的結果。該圖顯示了工作負載中所有查詢的查詢響應時間標準幾何平均數。它明確指出了從工作負載運行任意查詢時所期望的查詢性能。圖中的柱條比較了未使用星型聯接優化時的基準性能 (1.0) 和星型聯接優化後的性能。它們均是使用的 SQL Server 2008。

Figure 4 星型聯接優化後的性能改進 (單擊該圖像獲得較大視圖)

如圖所示，所有工作負載均有顯著改進（12% 到 30%）。儘管具體的優勢可能不盡相同，但是我們期望在 SQL Server 2008 中引入新的星型聯接特定優化擴展項後，針對 SQL Server 引擎的決策支持工作負載可改善約 15%–20%。

分區表並行處理

爲加快大型數據倉庫的查詢處理速度，數據庫管理員常常按日期對大型事實表進行分區。它將數據放到不同的文件組內，從而減少了處理某一數據範圍內的行時所必須搜索的數據量，並且當文件組被部署到多個物理磁盤上時，可利用底層磁盤系統的併發性能。

SQL Server 2005 可以將大型關係分成較小的邏輯塊，大型表的管理因而得以改善。它還被成功用於改善查詢處理，尤其是對於大型決策支持應用程序而言更顯成效。

遺憾地是，某些使用 SQL Server 2005 的客戶發現針對這些分區表的查詢存在性能問題 — 尤其是在並行共享內存多處理器機器上運行時。在 SQL Server 2005 中針對分區表處理並行查詢時，僅分配可用線程的一個子集執行查詢時會出現上述情況。

試想有一臺查詢最多可並行使用 64 個線程的 64 核機器，並且查詢會涉及兩個分區。使用 SQL Server 2005 時，它僅接收 64 個線程中的 2 個，因此可能僅使用了機器 CPU 能力的 2/64（3.1%）。據報告稱，對於相同的事實表，分區情況下的查詢性能可能比未分區時在相同機器上運行相同查詢時的性能要差 10 倍甚至更多。

需要注意的是，SQL Server 2005 針對涉及單個分區的查詢進行了專門優化。此時，查詢處理器會分配所有可用線程來執行掃描。這種特殊優化爲在多核機器上執行的單分區查詢帶來了顯著的性能提高，對於那些查詢涉及多個分區的客戶而言，他們當然也期待獲得這一提高。

SQL Server 2008 引入了新的分區表並行處理 (PTP) 功能，通過更好地利用現有硬件的處理能力（而不管查詢涉及多少個分區或者各個分區的相對大小如何），改進了分區情況下的查詢性能。在包含分區事實表的典型數據倉庫情形中，用戶會發現並行計劃的執行查詢有了顯著的改進，尤其是當可用處理器核數大於查詢所涉及的分區數時。該新功能默認啓用，無需任何調整或配置。

假設我們有一個分佈在四個分區中的事實表，它代表按銷售日期組織的銷售數據。圖 5 中的圖表將有助於您形象地描述該示例。請注意，這裏使用的並非針對整個日期範圍的單個聚集索引（就像在非分區時一樣），而是爲事實表中每個分區的日期列設定一個聚集索引。現在假設查詢 Q 彙總最近七天的銷售數據。由於新的銷售數據始終通過最後一個分區（即 P4）進入事實表，因此查詢很可能會涉及到不同的分區，具體視其執行時間而定。如圖表第一行所示，Q1 查詢僅涉及單個分區，而 Q2 查詢則涉及兩個分區，因爲執行時相關數據分佈在 P3 和 P4 分區上。

Figure 5 可用新 PTP 功能 (單擊該圖像獲得較大視圖)

現在假設有八個可用線程。在 SQL Server 2005 上執行 Q1 和 Q2 可能產生一些意外的行爲。SQL Server 2005 具有一個優化功能，如果優化器知道在編譯時查詢僅涉及一個分區，則會將該分區當作單個非分區表，並生成一個使用所有可用線程來訪問表的計劃。

這樣，涉及單個分區 (P3) 的 Q1 將生成由八個線程進行處理的計劃（未顯示）。對於涉及兩個分區的 Q2，執行程序向每個分區分配一個線程，即使底層硬件還有其他可用線程。因此，Q2 僅利用了可用 CPU 能力中極小的一部分，並且很可能執行速度明顯慢於 Q1。

在 SQL Server 2008 上執行 Q1 和 Q2 時，可用硬件利用率更高、性能更好並且對於行爲的預測能力也更強。對於 Q1，執行程序仍分配全部八個可用線程來處理 P2 中的數據（未顯示）。同時，Q2 則會產生一個並行計劃，其中的執行程序將以輪叫方式將所有可用線程分配給 P3 和 P4，因而產生圖中最下面一行所示的效果，其中兩個分區中的每個分區各獲得四個線程。CPU 得以充分利用，且 Q1 和 Q2 的性能不相仲伯。

通過該線程輪叫分配，如果處理器核數多於查詢所涉及的分區數，查詢的性能將更好。然而，遺憾地是，有時爲分區分配線程並不象示例中這麼簡單。

對於多核處理器機器上的分區表，圖 6 進一步顯示了從 SQL Server 2005 到 SQL Server 2008 所產生的性能改進。該圖表着重指出了分區表的掃描性能。對於這個在 64 核且 RAM 爲 256GB 的系統上執行的特殊測試，我們將 121GB 的單個表分成 11 個分區，每個均爲 11GB。對於該圖中所示的測試組，我們使用堆文件組織以及冷緩衝區和熱緩衝區啓動。所有查詢均對數據執行簡單掃描。

Figure 6 啓用了新 PTP 功能的 SQL Server 的掃描性能 (單擊該圖像獲得較大視圖)

y 軸顯示了響應時間（秒），x 軸表示並行度 (DOP)，它模擬分配給查詢的線程數。如您所見，在冷啓動和熱啓動兩種情況下，響應時間持續減少，直到 DOP 達到 22。此時，I/O 系統對於冷啓動情形變爲滿負荷狀態。其原因是本示例中使用的查詢受 I/O 限制。如果是受 CPU 限制的工作負載，該限制可能不存在，或者僅在 DOP 更高時纔會發生。

然而，代表熱啓動情形的曲線則隨着 DOP 級別的增加，其響應時間仍在繼續降低。對於 SQL Server 2005，在 DOP 11 附近，兩條曲線都開始變平，因爲在處理多個分區時，每個分區的線程數僅限於 1。

必須指出的一點是，實際上，增加 DOP 所取得的響應時間提高永遠不可能是線性的。預期的行爲更類似於階躍函數 — 它反映出查詢必須等待最慢的子件。因此，例如，僅向掃描再添加一個線程並不會加快查詢，除非所有其他掃描也獲得了能加快速度的其他線程。

對於其他各種硬件和文件配置，我們也通過其他試驗測試了新的 PTP 行爲。此時，在當 DOP 超過 1 線程/分區時，我們在吞吐量範圍中觀察到了類似行爲。

最後（但同樣重要），SQL Server 2008 中的新 PTP 功能還改善了查詢計劃的可讀性，並允許深入洞察具體工作負載的執行。例如，作爲 PTP 功能的一部分，在 showplan XML 中表示並行和串行計劃的方式已得到改進，並且編譯時和運行時執行計劃中提供的分區信息也已增強。

數據壓縮

隨着商業智能的日益普及，企業將越來越多的數據灌入到其數據倉庫中進行分析。這使得所管理的數據量呈指數級增長。在 1995 年，Winter Corporation 的第一份數據庫容量調查指出，當時全球最大的系統包含的數據量是 TB。十年之後，最大的數據庫擴大了近 100 倍。更令人驚訝的是數據倉庫的大小每兩年即增至原來的三倍。要管理如此大的數據併爲數據倉庫查詢提供可接受的性能，難度可想而知。這些查詢通常都非常複雜（涉及多個聯接和累計），並要訪問大量數據。工作負載中的許多查詢還都受 I/O 限制。

本機數據壓縮是這一問題的解決方案。SQL Server 2005 SP2 爲小數和數字型數據引入了一個新的可變長度存儲格式，即 vardecimal 存儲格式。這一新存儲格式可顯著降低數據庫的大小。而空間的節省又有助於在以下兩方面改善受 I/O 限制查詢的性能。首先，要讀取的頁面更少，其次，由於數據是以壓縮格式存儲在緩衝池中，因而提高了頁面預期壽命（換句話說，它加大了在緩存中找到所請求頁面的機率）。當然，由於需壓縮和解壓縮數據，從數據壓縮獲得的空間節省確實會產生一定的 CPU 開銷。

SQL Server 2008 基於 vardecimal 存儲格式構建，提供以下兩類壓縮：ROW 壓縮和 PAGE 壓縮。通過用可變長度存儲格式存儲所有固定長度的數據類型，ROW 壓縮擴展了 vardecimal 存儲格式。

固定長度數據類型示例包括：整數、字符和浮點數據類型。即使 SQL Server 將這些數據類型存儲成可變長度格式，數據類型的語義仍保持不變（從應用程序角度看，數據類型仍爲固定長度數據類型）。因此，既能從數據壓縮受益，又無需對應用程序做任何更改。

PAGE 壓縮將給定頁面上一行或多行的列數據冗餘降至最小。它使用 LZ78 (Lempel-Ziv) 算法的專有實現方法，在頁面上僅存儲一次冗餘數據，然後從多個列對其進行引用。請注意，在使用 PAGE 壓縮時，實際也包括了 ROW 壓縮。

可針對表、索引或者分區表和索引的一個或多個分區啓用 ROW 和 PAGE 壓縮。因此，可極其靈活地選擇要壓縮的表、索引和分區，在空間節省和 CPU 影響之間取得巧妙的平衡。圖 7 顯示了針對銷售表（通過對齊索引分區）實現的這一平衡。

Figure 7 具有不同壓縮設置的分區表 (單擊該圖像獲得較大視圖)

每個分區代表一個季度，其中“十月-十二月”爲最後一個季度。假設頭兩個分區的訪問頻率不高，第三個分區爲中等頻率，最後一個分區的訪問頻率最高。此例中，一個可能的配置爲前兩個分區啓用 PAGE 壓縮，這樣空間節省最大且對工作負載性能造成的影響最小，對第三個分區使用 ROW 壓縮，最後一個分區不使用任何壓縮。

可使用 Alter Table 或 Alter Index 數據定義語言 (DDL) 語句來聯機或脫機啓用壓縮。SQL Server 還提供用於估計空間節省量的存儲過程。所獲得的空間節省取決於壓縮對象的數據分佈和架構。

許多客戶數據庫的測試結果均顯示，大部分客戶都可將其數據庫的大小縮小 50–65%，並且受 I/O 限制的查詢的性能得到了顯著改善。然而，估計對受 CPU 限制查詢的性能影響則有點棘手，具體取決於查詢的複雜程度。在 SQL Server 中，僅當訪問索引或表時纔會發生解壓縮開銷。如果掃描運算符的相對 CPU 開銷低於查詢的整體 CPU 開銷（數據倉庫情形通常都是這樣），您會發現對 CPU 利用率的影響少於 20-30%。

分區對齊的索引視圖

在 SQL Server 2008 中，分區對齊的索引視圖允許您更加有效地在關係數據倉庫中創建和管理摘要彙總，並在之前無法有效使用它們的情形中使用它們。因而改進了查詢性能。通常，您會有一個按日期分區的事實表。會針對該表定義索引視圖（或摘要彙總）以加快查詢速度。如果切換到新的表分區中，針對該分區表定義的分區對齊的索引視圖的匹配分區也會相應切換，並且爲自動切換。

它是優於 SQL Server 2005 的一個重大改進，在 SQL Server 2005 中，必須丟棄針對分區表定義的所有索引視圖，然後才能使用 ALTER TABLE SWITCH 操作來切換入或切換出分區。SQL Server 2008 中的分區對齊索引視圖功能向您提供了針對大型分區表定義的索引視圖的各項好處，而不必對整個分區表重新構建彙總。這些好處包括自動維護彙總以及索引視圖匹配。

分區級鎖升級

SQL Server 支持範圍分區，即允許針對可管理性分區數據，或根據其使用模式對數據進行分組。因此，可按月度或季度等標準對銷售數據進行分區。可將分區映射到自身的文件組，再將文件組映射到一組文件。它提供了兩大好處。首先，可將分區作爲獨立的單元進行備份和恢復。第二，可根據使用模式或查詢負載將文件組映射到慢速或快速 I/O 子系統。

數據訪問模式是這裏非常有趣的特點。查詢和 DML 操作可能僅需訪問或處理分區的一個子集。舉例而言，如果要分析 2004 年度的銷售數據，僅需訪問相關的分區，理想情況下，不應受到併發訪問其他分區數據的查詢的影響（系統資源除外）。在 SQL Server 2005 中，併發訪問其他分區中的數據可能導致將表鎖定，從而影響對其他分區的訪問。

爲將該干擾降至最低，SQL Server 2008 引入了表級選項來控制分區級或表級的鎖升級。默認情況下，啓用表級的鎖升級（如 SQL Server 2005）。但，您可覆蓋表的鎖升級策略。例如，可按以下所示設置鎖升級：

Alter table <mytable> set (LOCK_ESCALATION = AUTO)

該命令指示 SQL Server 選擇適合於表架構的鎖升級粒度。如果表並未分區，則鎖升級爲表級。如果表已分區，則鎖升級粒度爲分區級。該選項還用作 SQL Server 反對錶級鎖粒度的提示。

結束語

SQL Server 2008 中提供了諸多有助於關係數據倉庫決策支持查詢提高性能的增強功能，本文僅做了簡要闡述。但是，請記住，儘管決策支持查詢的競爭性響應時間至關重要，仍存在其他關鍵要求，只是它們並不在本文討論範圍之內。

與關係數據倉庫相關的一些其他功能包括：

• 支持 T-SQL 中的 MERGE 語法，以使用一個語句更新、刪除或插入（維度）數據並瀏覽數據庫。
• 優化了 SQL Server 引擎的日誌記錄性能，從而提高了 ETL 效率。
• 將設置進行了分組，以便於在 T-SQL 中編寫彙總決策支持查詢。
• 對備份進行壓縮，以降低完整備份和增量備份的 I/O 需求。
• 對資源進行監管，以控制對不同工作負載的系統資源分配。