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 限制，從而縮小儲存需求。不但可減小基礎索引的儲存負擔，也能降低事實資料表的維護成本。資料倉儲中的維度資料表通常很小，一般可容納數千或多達數百萬的資料列。相較來看，事實資料表可能很大，存有上億至數十億的資料列。因此，邏輯設計真的應該特別注意事實資料表的儲存需求。

此一大小因素也意味著您應該根據維度資料表，判斷應選擇什麼索引鍵，來維護事實資料表/維度資料表的關聯性。以維度的商務索引鍵為主的複合索引鍵 — 也就是維度所代表的實體的真實世界識別碼 — 通常涵蓋了數個資料行。您應該要曉得，這對事實資料表中相對應的外部索引鍵會造成問題，因為事實資料表的每個資料列都將重複多個資料行的複合索引鍵。

應付這個問題有個常見的作法，您可以使用小型的 Surrogate 索引鍵來實作事實資料表及其維度之間的關聯性。Surrogate 索引鍵是一種整數類型的識別資料行，可作為維度資料表假造的主索引鍵。也因為事實資料表參考了較小的 Surrogate 索引鍵，大型事實資料表的儲存需求因此大幅降低。[圖 1] 顯示使用維度和事實資料表搭配 Surrogate 索引鍵的維度模型資料倉儲結構描述。

Figure 1** 含一個事實資料表和兩個維度資料表的星狀結構描述範例 **(按影像可放大)

雪花式結構描述設計會將一或數個維度分散到多個層級 (例如，某客戶維度的客戶、國家和地區)，因此可將資料當中有過度冗餘的較大型維度正規化。層級是由不同的資料表表示，使結構描述具備了雪花的形狀。另一方面，星狀結構描述設計則完全不會將它的維度分散到資料表上。星狀結構描述具備著星星的形狀，當中的維度資料表是以事實資料表為中心在周圍形成群組。

根據以維度作為模型的星狀結構描述或雪花式結構描述，其決策支援查詢遵循著一套典型的模式：查詢從事實資料表選取幾個感興趣的量值，將事實資料列與一或數個維度連同 Surrogate 索引鍵相聯結，在維度資料表的商務資料行上放置篩選器述詞，根據一或數個商務資料行分組，然後經過一段時間後彙總事實資料表擷取到的量值。下面示範了這種模式，這種模式也稱為星狀聯結查詢：

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 中，資料倉儲設計人員通常是先從藍圖或實體設計著手，然後應工作負載的變化微調、修整。您應該針對自己的資料倉儲環境採納和更改這個藍圖。在這麼做的時候，千萬別忘了資料庫實體設計的最佳作法，例如針對更新進行索引維護所產生的效能衝擊以及索引的儲存需求。

事實資料表

藍圖設計的目的是要預估典型的星狀查詢的形狀，並根據事實資料表來建置索引。事實資料表的叢集索引採用了數個維度 Surrogate 索引鍵資料行 (外部索引鍵資料行) 作為索引鍵。最常用的資料行應該會出現在索引鍵清單中。您應該花點時間，確認這的確為您工作負載當中最常執行的查詢提供了良好的存取路徑。

此外，藍圖還會為事實資料表中的每個維度 Surrogate (外部索引鍵) 資料行建立單一資料行的非叢集索引。這可為其中一個維度選擇性高的查詢提供高效的存取路徑。

叢集索引的目標是要為您工作負載當中的絕大多數查詢提供良好的效能。非叢集索引則是以擷取特定客戶或產品的事實資料表量值的查詢為目標。比方說，這些非叢集索引讓您在擷取單一客戶的銷售資料時，不用掃描事實資料表。

維度資料表

將藍圖設計套用到維度資料表時，您必須為每個維度資料表建立索引。其中包括在維度的 Surrogate 索引鍵資料行上建立非叢集主索引鍵限制索引，以及在維度實體的商務索引鍵資料行上建立叢集索引。對於大型的維度資料表，您還應該考慮在最常用於高度選擇性述詞中的資料行上，新增非叢集索引。

叢集索引可在資料倉儲的維護期間加速有效的擷取、轉換和載入 (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 如何利用這些點陣圖篩選器在星狀聯結查詢執行期間提升聯結的效能。此圖顯示針對兩個維度資料表 (產品和時間) 與事實資料表連同 Surrogate 索引鍵進行查詢的計畫。此查詢對兩個維度資料表使用篩選器述詞，例如 WHERE 子句，只讓一個資料列取得一個維度。這是由兩個聯結運算子旁邊的紅色小資料表表示。

Figure 3** 星狀聯結查詢計畫與簡化聯結處理 **(按影像可放大)

每個聯結的聯結實作都是雜湊聯結，這可讓 SQL Server 將合格資料列的相關資訊，從維度資料表套用成我們所謂的兩個維度資料表的簡化聯結資訊。圖中的綠色方塊表示簡化聯結資訊資料結構。一旦從基礎維度資料表擴展之後，SQL Server 就會在查詢執行期間，自動將這些資料結構移到運算子來處理事實資料表，例如資料表掃描。這個運算子會利用維度資料表資料列的相關資訊，來去除對維度來說不符合聯結條件的事實資料表資料列。

SQL Server 會在極早期的查詢處理期間清除這些事實資料表資料列 — 在從事實資料表擷取資料列之後。這可同時省下 CPU 和可能的磁碟 I/O，因為查詢計畫的其他運算子中並不需要處理這些被清除的資料列。SQL Server 使用點陣圖表示以便在查詢執行時期，有效地實作聯結簡化資訊資料結構。

星狀聯結最佳化管線

最佳化程序是採用標準啟發式 (Heuristic) 來達成聯結查詢最佳化，以產生一組初始的查詢執行計畫替代方案。接著會運用特殊用途的延伸模組來產生其他的查詢計畫替代方案。

在資料倉儲的情況下，延伸模組會偵測星狀結構描述、雪花式結構描述，以及星狀查詢模式，而且它會評估查詢對事實資料表的選擇性。如果結構描述和查詢形狀符合模式，SQL Server 就會自動新增更多查詢計畫到計畫空間，此空間隨後會佈滿以成本為考量的最佳化，來選擇最有可能的查詢計畫來執行。

在查詢執行時期，SQL Server 還會監視簡化聯結在執行時期的實際選擇性。如果選擇性有所變更，SQL Server 會動態地重新排列簡化聯結資訊資料結構，讓選擇性最高的最先套用。

星狀聯結啟發式

許多資料倉儲的實體設計都是遵循星狀結構描述，但不會完全指定事實和維度資料表之間的關聯性，例如像前文所述的外部索引鍵限制。若未明確指定外部索引鍵限制，SQL Server 就必須仰賴啟發式來偵測星狀結構查詢模式。偵測星狀聯結查詢模式會套用下列的啟發式：

1. 加入 N 元聯結的最大資料表將被視為事實資料表。事實資料表的大小下限還有其他限制。比方說，若是連最大的資料表都未超過特定大小，N 元聯結將不會被視作星狀聯結。
2. 星狀聯結查詢中的二進位聯結的所有聯結條件，都必須是單一資料行相等述詞。聯結必須是內部聯結，這聽起來好像很嚴格，但它涵蓋了典型星狀結構描述中的 Surrogate 索引鍵上的事實資料表與維度資料表之間絕大多數的聯結。如果聯結具有比較複雜的聯結條件，而與前述的模式不符，便會將該聯結從星狀聯結中排除。譬如，如果五向聯結當中的兩個聯結擁有比較複雜的聯結述詞，則可能變成三向星狀聯結 (之後會納入其他兩個聯結)。

要注意的是，這些是啟發式規則。會導致啟發式挑選維度資料表作為事實資料表的實際情況不多。這雖會左右計畫的選擇，但對選定計畫的正確性卻完全沒有影響。星狀聯結中所牽涉的二進位聯結之後會依漸低的選擇性來排序。此處所提的聯結選擇性是定義成事實資料表的輸入基數與聯結的結果基數的比率 — 聯結選擇性會指明某特定維度會減少多少的事實資料表基數。一般來說，我們會先考慮含較高選擇性的聯結。

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 引擎的決策支援工作負載，將可改進大約 15-20%，視 SQL Server 2008 中全新的星狀聯結特定最佳化的延伸模組而定。

分割資料表平行處理

為了加速大型資料倉儲中的查詢處理，資料庫管理員通常會依日期來分割大型事實資料表。這會將資料放置到不同的檔案群組中，除了可在處理特定資料範圍內的資料列時減少必須搜尋的資料量外，還能在將檔案群組部署到大量實體磁碟時，善用基本磁碟系統的並行效能。

SQL Server 2005 引進了將大型關聯分割成較小邏輯區塊，以改善大型資料表管理工作的功能。它在改進查詢處理能力方面亦成就非凡，尤其是大型決策支援應用程式。

不幸的是，有些使用 SQL Server 2005 的客戶在這些分割資料表上觀察到與查詢相關的效能問題 — 特別是在執行平行共用記憶體多處理器的機器上。當在 SQL Server 2005 中的分割資料表上處理平行查詢時，可能會發生只指派了可用的執行緒子集來執行查詢的情況。

想想 64 核心的機器，當中的查詢可平行使用多達 64 個執行緒，而且每個查詢會到達兩個磁碟分割。在 SQL Server 2005 中，它只會收到 64 個執行緒中的兩個，因此可能只會使用機器 2/64 (3.1%) 的 CPU 功力。有些查詢在磁碟分割的情況下的效能，遠比在相同機器上相同事實資料表的非分割版本上執行相同的查詢要差上 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 的效能相當。

當處理器核心比查詢存取的磁碟分割數目更多時，這類的執行緒循環配置可讓查詢效能格外出色。但可惜的是，磁碟分割的執行緒配置在某些情況下並不如本例般直接了當。

從 SQL Server 2005 到 SQL Server 2008 針對分割資料表案例在多核心處理器機器上所獲得的效能提升，在 [圖 6] 有進一步說明。這個有趣的圖表指出了分割資料表的掃描效能。針對這項在配備 64 核心和 256GB RAM 的系統上進行的特定測試，我們將 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 增加超過一個執行緒/磁碟分割，在調整輸送量方面類似的行為。

最後也是很重要的一點是，SQL Server 2008 的 PTP 新功能也提高了查詢計畫的可讀性，以便更進一步了解特定工作負載的執行。譬如，顯示計畫 XML 中呈現平行和序列計畫的方式已經過改良，還有編譯時期和執行階段兩個執行計畫所提供的磁碟分割資訊也已經過加強，這些都屬於 PTP 功能的一部分。

資料壓縮

隨著商務智慧越來越普遍，各公司也將越來越多的資料倒入資料倉儲裡面進行分析。結果變成要管理的資料大小成指數成長。在 1995 年，第一份 Winter Corporation 關於資料庫大小的調查指出，全世界最大的系統包含的資料量是以 TB 為單位。十年之後，最大的資料庫更是加大 100 倍。更驚人事實是，資料倉儲的大小每兩年就增加三倍。要管理這麼大量的資料，以及為資料倉儲查詢提供可接受的效能等級，在在都是新挑戰。這些查詢往往複雜，牽涉到許多聯結和彙總，而且它們也會存取大量的資料。另外，工作負載當中很多查詢繫結 I/O 的情況也很常見。

原始資料壓縮正是要解決這個問題。SQL Server 2005 SP2 為小數點和數值資料引進了一個全新的變數長度儲存格式，也就是 Vardecimal 儲存格式。這個全新的儲存格式可大幅縮減資料庫的大小。節省下來的空間可在兩方面協助提升繫結 I/O 查詢的效能。首先，要讀取的頁面變少了，其次，因為資料是以壓縮的形式保存在緩衝區集區中，所以它可增進 Page Life Expectancy (換句話說，它能提高在緩衝區中找出要求頁面的機會)。不用說，因為要進行壓縮和解壓縮程序，透過資料壓縮省下的空間的確也產生了 CPU 方面的成本。

SQL Server 2008 是以 Vardecimal 儲存格式為基礎建構而成，提供兩種壓縮方式：ROW 壓縮和 PAGE 壓縮。ROW 壓縮會以變數長度儲存格式來儲存所有固定長度的資料類型，藉此延伸 Vardecimal 儲存格式。

Integer、char 和 float 資料類型都屬於固定長度資料類型。即使 SQL Server 是以變數長度格式來儲存這些資料類型，資料類型的語意還是不變 (從應用程式的角度來看，資料類型仍舊是固定長度的資料類型)。也就是說，您不需要對應用程式進行任何變更，就可以坐享資料壓縮的好處。

PAGE 壓縮可將特定頁面上的一或多個資料列中資料行內的資料重複降至最低。它使用 LZ78 (Lempel-Ziv) 演算法的專利實作，只在頁面上儲存重複資料一次，然後從多個資料行參考它。要注意的是，當您使用 PAGE 壓縮時，實際上也會包含 ROW 壓縮。

資料表或索引，或分割資料表和索引的一或多個磁碟分割，都可以啟用 ROW 和 PAGE 壓縮。這提供極大的彈性供您選擇要進行壓縮的資料表、索引和磁碟分割，讓您在節省空間和 CPU 衝擊之間找出平衡點。[圖 7] 透過不同索引對齊的方式分割的銷售資料表，來說明這種情況。

Figure 7** 含有不同壓縮設定的分割資料表 **(按影像可放大)

每個磁碟分割都代表一季，十月-十二月是最後一季。假設前兩個磁碟分割並不常存取，第三個磁碟分割的活動平平，而最後一個磁碟分割的活動最多。在這種情況下，可能的組態是在前兩個磁碟分割上啟用 PAGE 壓縮，以盡可能不影響工作負載效能的情況下節省最大的空間，在第三個磁碟分割上啟用 ROW 壓縮，最後一個磁碟分割則不進行任何壓縮。

您可以使用 Alter Table 或 Alter Index Data Definition Language (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 需求。
• 資源監管以控制配置到不同工作負載的系統資源。

我們非常鼓勵您到 SQL Server 網頁上瞧瞧所有這些新酷功能的相關詳細資訊，網址是 microsoft.com/sql。

在此特別感謝 Boris Baryshnikov、Prem Mehra、Peter Zabback 和 Shin Zhang 貢獻技術長才。

Sunil Agarwal 在 Microsoft 的 SQL Server 儲存體引擎 (SQL Server Storage Engine) 小組擔任資深專案經理，他負責並行、索引、tempdb、LOBS、支援性和大量匯入/匯出。

Torsten Grabs 在 Microsoft SQL Server 小組中擔任核心儲存體引擎 (Core Storage Engine) 的資深專案經理，他擁有資料庫系統的博士學位，並且在 SQL Server 方面有 10 年的經驗。

Dr. Joachim Hammer 在 Microsoft 的查詢處理 (Query Processing) 小組擔任專案經理，他擅長於大規模資料倉儲應用程式的查詢最佳化，也專精分散式查詢、ETL 和資訊整合。

© 2008 Microsoft Corporation and CMP Media, LLC. 保留所有權利；未經允許，嚴禁部分或全部複製.