1. 導言

Microsoft SQL Server 2008提供了一個全面的數據倉庫平臺。它使得你可以使用一套單獨的、整合的產品套件建立和管理你的數據倉庫，并使你可以為你的用戶提供洞察信息。它可以滿足最大規模企業的需求，給予你的終端用戶和IT員工所需的權利。

在SQL Server 2008版本中部署方面首先要關注的是要改進整個產品套件的可擴展性以充分滿足大型企業的需求。這里，我們將介紹我們已經添加的用于改進你的數據倉庫體驗的特性和改進之處。建立、管理、傳送。SQL Server 2008使你很輕松地做到所有這些。

2. 新的數據倉庫特性圖解

下面的表格顯示了SQL Server 2008中新的可擴展特性，以及它們在數據倉庫(DW)的哪方面可以提供幫助。

這篇文章簡要地描述了在SQL Server 2008每一個不同組件中的數據倉庫改進之處，以及它們怎樣幫助你從你的數據倉庫獲得最大的受益。

#p#

3. SQL Server關系型數據庫管理系統數據倉庫改進之處

SQL Server 2008關系型數據庫管理系統與之前的版本相比改進了很多，所以它在你創建、管理和查詢大型數據倉庫時執行得更為出色。這一章節將詳細講述表1中列出的關系型數據庫管理系統數據倉庫改進之處。

3.1 星型關聯

有了維度模式的數據倉庫，你工作的很大一部分就包含了眾所周知的星型關聯查詢。這些查詢遵循一個公共模式，它將真實表和一個或多個維表關聯起來。此外，星型關聯查詢通常表達對維表的非主鍵字段過濾條件，并對真實表的一個字段(叫做measure字段)進行聚合(一般是SUM)。有了SQL Server 2008，你將會體驗到許多處理真實表大部分記錄的星型關聯查詢其性能獲得了極大的提高。新的技術是基于位圖過濾器的，也就是眾所周知的Bloom 過濾器。它使得SQL Server 可以在早期查詢評估中就除去不具資格的真實表記錄從而避免進行進一步的處理。這與SQL Server的競爭產品所使用的處理技術相比節省了大量的CPU時間。你獲得的結果可能很多，我們的統計結果是一般情況下，當使用新的星型關聯查詢處理能力時整個關系型數據倉庫查詢工作負載的性能提高了15-20%。一些個別的查詢速度提高了7倍或更多。

新的星型關聯最優化使用了一系列哈希關聯，為每一個參與的維表建立一個哈希表。隨著這個哈希表的建立，還生成了叫做位圖過濾器(bitmap filter)的額外信息。位圖過濾器如圖1中顯示標簽為“Join Reduction Info”的框圖。這些過濾器被放在事實表的掃描中，有效地將之后會被關聯刪除的大多數記錄移除。這使得之后不必再花費時間拷貝被刪除的記錄和從它們那里探測哈希表。這個插圖顯示了在事實表掃描中過濾器的效果。SQL Server 2008查詢執行器還可以在執行過程中重新定制位圖，將最想選擇的放在最先，第二想選擇的放在其次，以此類推。這節省了更多CPU時間，因為一旦一個真實表記錄對位圖檢查失敗，那么這個記錄就會被跳過。

在Microsoft SQL Server 2008企業版中可以使用新的星型關聯最優化。在SQL Server中的查詢處理器會自動對查詢按照星型關聯模式應用最優化，在這樣的評估查詢成本較低的情況下。你不需要對你的應用程序做任何修改以獲得這個顯著的性能改進。

3.2 分區表并行

你不想從你所擁有的硬件獲得最高的性能嗎?在SQL Server 2008中的分區表并行(partitioned table parallelism，PTP)特性能夠幫助你。數據倉庫應用程序一般收集大量的事實表歷史數據，這些數據通常按日期分區。在SQL Server 2005中，接觸不只一個分區的查詢對每個分區使用一個進程(并因此一個處理器內核)。這有時會限制涉及分區表的查詢性能，特別是當運行在具有多個處理器內核的并行共享內存多處理器(SMP)計算機的時候。分區表并行通過更好地利用現有硬件的處理器能力，改進了分區表的并行查詢計劃性能，無論一個查詢接觸多少分區。這個功能默認執行，不需要手動調整或配置。下圖顯示了在一個典型數據倉庫場景中分區表并行的影響。

 
圖 2: 分區表并行

假設我們有一個真實表，它顯示四個分區中按照銷售日期組織的銷售數據，每一個都包含七天的數據，如圖表的上部分所顯示。查詢Q 是過去七天的銷售總和。這個查詢取決于它執行的時間可以作用于不同的分區。如查詢Q1所示，它接觸一個單獨的分區P2并被Q2接觸，而Q2接觸兩個分區，因為相關的數據在執行時跨過了P3和P4。

在SQL Server 2005中執行Q1和Q2可能會產生一些意料外的活動。因為有一個可以分派所有線程到一個單獨的分區查詢上的特殊情況邏輯，Q1的結果是由所有可用線程處理、圍繞P3的并行計劃(執行沒有在圖中顯示)。但是在Q2的情況下，執行器將每一個單獨線程分派到分區P3和P4，即使后臺硬件擁有可用的額外線程。因此在8-way計算機上，Q2只利用可用CPU的2/8(25%)，而且很可能比Q1執行得要慢得多。

在SQL Server 2008中執行Q1和Q2會更好地利用可用硬件，因此具有更好的性能和更可預測的動作。在Q1的情況下，執行器再一次分配所有可用的線程來處理P2中的數據(沒有顯示)。Q2生成一個并行計劃，其中執行器以輪流方式指派所有可用線程到P3和P4，它產生的作用在圖中New Allocation下面做了顯示說明。CPU仍然是完全利用，而Q1和Q2的性能是差不多的。在這種新的線程輪流指派方式下，分區表并行提供的性能提高就變得很明顯了，而且更多的處理器內核與受一個查詢影響的分區數目是可比的。當一個查詢訪問的所有數據是在主內存緩沖池中——這對于最近的分區來說是種典型情況，我們在對接觸兩個分區的查詢進行的內部測試中獲得了16倍或更快的速度。而實際結果取決于查詢、數據組織和硬件配置。

#p#

3.3 對齊分區索引視圖

對齊分區索引視圖使你能夠更有效地創建和管理在你關系型數據倉庫中的聚合，并能夠在以前不能有效使用它們的場合中使用它們，改進了查詢性能。在一個典型場景中，你有一個事實表，它是按日期分區的。索引視圖(聚合)定義在這個表上，以幫助加快查詢。當你轉到一個新的表分區時，定義在分區表上的對齊分區索引視圖的匹配分區就也轉過去了，并且是自動這么做的。

這與SQL Server 2005相比是個顯著的提高，在SQL Server 2005中你必須在使用ALTER TABLE SWITCH操作以轉入或轉出一個分區之前，刪除所有定義在一個分區表上的索引視圖。SQL Server 2008中的對齊分區索引視圖特性使你受益于大型分區表上的索引視圖，同時節省了在整個分區表上重建聚合的成本。這些受益包括自動維護聚合，以及索引視圖匹配(自動查詢重寫以利用聚合解決只涉及基礎表而不涉及聚合的查詢)。

下圖顯示了在一個分區里轉向時聚合怎樣隨著基礎表分區移動。

 
圖 3: 對齊分區索引視圖

3.4 GROUPING SETS

GROUPING SETS使你可以編寫一個生成多個組并返回一個單獨結果集的查詢。這個結果集等同于對不同的分組記錄進行UNION ALL。使用GROUPING SETS，你可以關注于你的業務所需要的不同級別信息(分組)，而不僅僅是結合幾個查詢結果的機制。GROUPING SETS通過改進的查詢性能使你可以很簡單地編寫具有多個分組的報表。

在這個簡單但很典型的例子里，使用AdventureWorksDW樣例數據庫，你可能會在制作報表階段想看看下面的聚合：

◆按季度和國家統計的總銷售量

◆所有國家按季節統計的總銷售量

◆總銷售量

如果沒有GROUPING SETS ，那么你要獲得這個結果就必須運行多個查詢，或者如果你想要一個結果集的話，使用UNION ALL 結合這些查詢。有了GROUPING SETS ，你的查詢可以使用如下形式：

SELECT D.CalendarYear, D.CalendarQuarter, T.SalesTerritoryCountry
  , SUM(F.SalesAmount) AS SalesAmount
FROM dbo.FactResellerSales F   
  INNER JOIN dbo.DimTime D ON F.OrderDateKey = D.TimeKey
  INNER JOIN dbo.DimSalesTerritory T ON 
   F.SalesTerritoryKey = T.SalesTerritoryKey 
WHERE D.CalendarYear IN (2003,2004) 
GROUP BY GROUPING SETS (
    (CalendarYear, CalendarQuarter, SalesTerritoryCountry)
  , (CalendarYear, CalendarQuarter)  
  , () )
ORDER BY D.CalendarYear, D.CalendarQuarter, T.SalesTerritoryCountry

一般情況下，你將這個查詢的結果顯示為樞軸表類型，如下所示：

 
表2： 一個GROUPING SETS查詢的輸出，格式化為樞軸表

隨著可能的分組數目的增加，GROUPING SETS 所提供的簡潔性和性能優勢就越來越大了。

#p#

3.5 MERGE

MERGE 語句允許你在一個Transact-SQL語句中對一個表或視圖執行多個數據庫操縱語言(DML)操作(INSERT、UPDATE和DELETE)。目標表或視圖與一個數據源關聯起來，這些DML操作執行于這個關聯的結果。MERGE 語句有三個WHEN 條件子句，每一個都使你可以對結果集中的一個給定記錄執行一個專門的DML動作：

· 對于同時存在于目標表和源表中的每一條記錄，WHEN MATCHED 條件子句允許你對目標表中的給定記錄執行更新或刪除。

· 對于存在于源表中而不存在于目標表中的每一條記錄，WHEN [TARGET] NOT MATCHED 條件子句允許你插入一條記錄到目標表中。

· 對于存在于目標表中而不存在于源表中的每一條記錄，WHEN SOURCE NOT MATCHED 條件子句允許你更新或刪除目標表中的給定記錄。

你還可以對每一個WHEN條件子句指定一個搜索條件來選擇要對記錄執行哪種類型的DML操作。MERGE語句的OUTPUT條件子句包括一個新的虛擬字段，叫做$action，你可以使用它來標識執行于每一條記錄的DML操作。

在數據倉庫環境中，MERGE 語句用來執行對緩慢變化維(SCD)有效的插入和刪除操作以及在很多普通場景中維護真實表。MERGE 語句比運行單獨的插入、更新和刪除語句具有更好的性能特性，因為它只要求傳遞過來數據。

SQL Server 2008還推出了一個對插入語句的強大擴展功能，它允許插入語句使用嵌套INSERT、UPDATE、DELETE或MERGE 語句的OUTPUT 條件子句返回的記錄。

假設你有一個DimBook表(ISBN、Price、IsCurrent)，它跟蹤一個書庫中每一本書的歷史價格記錄和當前的價格。價格的改變和添加新書是每周進行的。每星期會生成一個源表WeeklyChanges (ISBN、Price)，這些變更會應用于DimBook 表。每一本新書都會插入一條記錄。在這一周改變了價格的現有書籍會以IsCurrent=0進行更新，并且會插入一條新記錄以反映這個新價格。下面這個Transact-SQL 語句使用新的MERGE和INSERT功能執行了這些操作。

INSERT INTO DimBook(ISBN, Price, IsCurrent)
    SELECT ISBN, Price, 1
    FROM
    (
        MERGE DimBook as book
        USING WeeklyChanges AS src
        ON (book.ISBN = src.ISBN and book.IsCurrent = 1)
        WHEN MATCHED THEN
            UPDATE SET book.IsCurrent = 0
        WHEN NOT MATCHED THEN
            INSERT VALUES (src.ISBN, src.Price, 1)
        OUTPUT $action, src.ISBN, src.Price
    ) AS Changes(action, ISBN, Price)
    WHERE action = 'UPDATE';

3.6 變化數據捕捉

變化數據捕捉(CDC)是SQL Server 2008中推出的一個新的數據跟蹤特性。主要是為數據倉庫場景設計的，改變數據捕捉提供了一個跟蹤和獲取對用戶表所做的數據改動的有效機制，并使你能夠以一種簡單使用的關系型格式來訪問變更數據。一般情況下，你在一個操作數據庫中使用CDC來捕捉變更用于之后轉移到你的數據倉庫中。在SQL Server中CDC的使用使得不再需要使用插入的方法，例如用戶觸發器、時間戳字段、以及高昂的查詢來確定操作系統中什么發生了改變。

與變化數據一起獲得的輔助信息使得CDC可以提供許多問題的答案。例如，這里有一些CDC可以有效提供答案的問題集：

◆我想要所有在12:00 A.M.和12:00 P.M 之間改變了的記錄。

◆我想要知道這個改變是插入、更新、還是刪除。

◆對于一條更新記錄，我想知道哪個(些)字段改變了。

CDC可以極為有用的場景之一是提取、轉換和加載(ETL)。隨著數據量的增加和由于全局操作使得維護窗口的縮減，優化ETL處理變得尤為重要。變化數據捕捉為你提供了一個非常有用的方法在擴大的基礎上提取變化，降低整個ETL處理時間。

下圖提供了對變化數據捕捉的組成組件概述。

 
圖 4: 改變數據捕捉

CDC使用一個捕捉工作從SQL Server事務日志中提取變更信息，生成變更表。CDC API使你可以編寫一個應用程序用以從變更表中獲得信息。你可以在你的ETL包中使用它。CDC清除工作刪除了變更表中不再需要的信息。

#p#

3.7 最低限度日志記錄INSERT

一般情況下，當你往一個數據庫中寫數據時，你必須將它寫到磁盤兩次：一次是寫到日志，一次是寫到它本身數據庫上。這是因為數據庫系統使用一個undo/redo 日志，所以它可以在需要的情況下回滾或重做事務。但是它只能在某些重要的情況(涉及插入數據到現有的表中，從而加速你的ETL處理速度的情況)下將數據寫到磁盤一次。這就是SQL Server 2008中新的最低限度日志記錄INSERT特性。

最低限度日志記錄包括只記錄回滾所不支持實時恢復的事務所需要的信息。最低限度日志記錄只在批量日志記錄和簡單恢復模型情況下可用。當一個最低限度日志記錄事務提交時，會發布一個檢查點用以將臟數據頁面發送到磁盤并截斷日志。最低限度日志記錄通過提高性能和降低所需日志空間大小，從而極大地改進了大規模INSERT操作。特別是，你必須對目標表使用表鎖(TABLOCK)。

在SQL 2005中可以最低限度日志記錄的操作包括批量導入操作、SELECT INTO 、以及索引創建和重建。SQL 2008將之擴展到INSERT INTO…SELECT FROM T-SQL 操作，它在滿足下列條件之一的情況下插入大量記錄到一個已有的表中：

◆插入記錄到一個具有集群索引而沒有非集群索引的空表

◆插入到一個沒有索引但是可以是非空的堆里面

一個使用最低限度日志記錄INSERT的主要場景是：你在特定的文件組上創建一個空表，所以你可以控制數據放置的物理位置。然后你使用INSERT INTO…SELECT FROM 來組裝它，以一種最低限度日志記錄的形式。這將數據放置在你想放置的地方，并且只將它寫到磁盤一次。

3.8 數據壓縮

在SQL Server 2008中新的數據壓縮特性通過以可變長度存儲的形式存儲固定長度的數據，以及降低冗余數據，從而降低了表、索引或它們分區的子集的大小。能夠節省的空間大小取決于schema和數據的分布。基于我們使用大量數據倉庫數據庫進行的測試，我們得到的統計情況是真實的用戶數據庫的大小會降低到87%(7比1的壓縮比)，但是更多情況下，你可能能降低到50-70%的范圍(壓縮比大約在2比1到3比1之間)。

SQL Server 提供了兩種壓縮類型，如下所示：

◆行壓縮使得可以以可變長度存儲格式來存儲固定長度類型。所以舉例來說，如果你有一個字段數據類型為BIGINT，它固定格式為占據8個字節的存儲空間，壓縮之后它使用了可變的字節數——從0到8的字節數。因為字段值是以可變長度來存儲的，而在一個記錄里每個字段會存儲一個額外的4比特長度代碼。此外，0和NULL值除了這個4比特代碼之外不占任何存儲空間。

◆頁面壓縮是建立于行壓縮的基礎上的。它存儲一次頁面上普遍使用的字節格式，然后將這些值引用給各自的字段，通過這種方法將冗余數據的存儲降低到最小。字節格式標識是不受類型約束的。在頁面壓縮中，SQL Server使用兩種技術優化頁面使用的空間。

第一個技術是字段。在這種情景下，系統尋找一個公共字節格式作為頁面上記錄的一個特定字段所有值的一個前綴。表或索引的所有字段都重復這個過程。計算得來的這個字段前綴值作為一個錨記錄存儲，數據或索引記錄將這個錨記錄作為公共前綴參考，如果可能的話，每一個字段都這么做。

第二個技術是頁面級字典。這個字典存儲字段和行的公共值，并存儲在一個字典中。然后字段會被修改以引用字典入口。

壓縮伴隨著額外的CPU成本。這是在你對壓縮數據進行查詢或執行DML操作時被耗費的。行壓縮耗費的相關CPU成本低于頁面壓縮，但是頁面壓縮可以提供更好的壓縮。因為有很多種工作負載和數據格式，所以SQL Server 將壓縮粒度定為分區級別。你可以選擇壓縮整個表或索引或分區子集。例如，在一個數據倉庫工作負載中，如果CPU是你的工作負載的主要成本，但是你想節省一些磁盤空間，那么你可能希望在不常被訪問到的分區上使用頁面壓縮，而不壓縮經常被訪問和操縱的當前分區(一個或多個)。這降低了總的CPU成本，而所需的磁盤空間稍稍多了一些。如果I/O成本是你的工作負載的主要成本，或者你需要降低磁盤空間成本，那么使用頁面壓縮來壓縮所有的數據可能是最好的選擇。如果壓縮使得你經常接觸頁面的工作集緩存在主要內存緩沖池中，那它可以將速度提高好幾倍，而如果它是放在內存中的話就不會這樣了。對一個用來測試SQL Server 2008的大型內部數據倉庫查詢性能基準的初步性能測試結果顯示節省了58%的磁盤空間、平均降低了15%的查詢運行時間、以及CPU成本平均提高了20%。而一些查詢速度提高了七倍。你的結果取決于你的工作負載、數據庫和硬件。

壓縮數據的命令是在CREATE/ALTER DDL語句中作為選項提供的，并且支持ONLINE和OFFLINE 模式。此外，還提供了一個存儲過程用來幫助你在實際壓縮前估計能夠節省的空間。

3.9 備份壓縮

備份壓縮幫助你以多種方式節省空間。

通過降低你的SQL備份的大小，你的SQL備份可以節省很多磁盤媒質空間。所有的壓縮結果依賴于進行壓縮的數據本身，壓縮到50%不是很少見的，也有可能壓縮到更小。這使得你可以使用較少的存儲以保持你的備份在線，或者使用相同的存儲保持更多的備份版本在線。

備份壓縮還幫助你節省了時間。傳統的SQL備份幾乎完全是受I/O性能的限制。通過降低備份過程的I/O負載，我們實際上加快了備份和恢復的速度。

當然，沒有什么是完全免費的，它在空間和時間上的降低是以耗費CPU為代價的。好消息是I/O時間的節省彌補了CPU時間的增加，而且你可以利用資源監控器控制你的備份以工作負載為代價使用多少CPU。

#p#

3.10 資源監控器

SQL Server 2008中新的資源監控器使你可以控制分配給你的關系型數據庫工作負載不同部分的CPU和內存資源的數量。它可以用來防止失控查詢(它阻止資源分配給其它工作負載)以及為你的工作負載重要部分預留資源。SQL Server 2005資源策略平等地對待所有的工作負載，并按需分配共享資源(例如，CPU帶寬、內存)。這有時會引起資源分配不按比例，從而導致性能不均衡或意料外的速度降低。

資源監控器的首要目標如下所示：

a. 監控：使得可以監控每組請求的資源消耗(工作負載分組)。

b. 可預測性：使得能夠對存在資源競爭的環境中預測工作負載的執行。這是通過顯示制定工作負載間的資源邊界來完成的(通過資源池控制)。資源邊界的使用還能防止或降低查詢失控的可能性。資源監控器所提供的監控功能使得更容易發現失控查詢。

c. 優先級：使得可以設置工作負載優先級。

要理解資源監控器，有三個新的概念是很重要的：工作負載分組、資源池、分類(和分類器用戶定義的函數)。

◆組：一個工作負載組，或組，是一個用戶指定的請求分類，它與應用于每一個請求的分類規則類似。組的值存在于資源消耗聚合監控和一個用于組內所有請求的統一政策中。組定義了用于它的成員的政策。

◆池：一個資源池，或池，它顯示了服務器一部分物理資源。根據它的設置，池可以有固定大小(每一個的最大和最小資源使用設置是相等的)或者在多個池之間共享一部分(它的最小小于它可用的最大設置)。在這種情形下，共享只是意味著資源提供給最先請求資源的池。在默認配置下，所有的資源都是共享的，因此維護向后兼容SQL Server 2005政策。

分類：分類是一組用戶編寫的規則，使得資源監控器可以將請求分類到之前描述的組里面。它是通過一個梯度Transact-SQL用戶定義的函數(UDF)來執行的，UDF旨在作為資源監控器的一個“分類器UDF”。

這些概念在下面的圖片里進行了描述。

 
圖5: 資源監控器例子：請求、分類、組，以及池

資源監控器可以用在沒有任何應用程序改動的情況下。

#p#

4. 集成服務的改進

進行ETL將數據從你的操作系統中移到你的數據倉庫里會是一個要求時間的工作。為了使這個過程更快，SQL Server 2008集成服務(SSIS)推出了兩個重要的可擴展性特性：改進的Lookup性能和改進的轉移管道性能。

4.1 Lookup性能

在SSIS中的Lookup 組件運行得更快，并且比在SQL Server 2005中更容易編程。一個lookup測試在記錄流里每一行記錄是否在另一個數據集里有一個相匹配記錄。一個lookup就像一個數據庫關聯操作。一般情況下，你在整合過程中使用lookup，例如從源系統獲得信息組裝一個數據倉庫的ETL層。

一個lookup建立一個用于保存從探測數據集獲得記錄的緩存。在SQL Server 2005中，Lookup組件只能從特定的OleDb連接里獲得數據，而且緩存內容只能使用一個SQL查詢來獲得。在SQL Server 2008中，新版本的Lookup使你可以使用一個在同一個包或不同包里的單獨管道來生成緩存的內容。你可以使用任何地方而來的源數據。

SQL Server 2005在每次使用緩存的時候將它重新加載。例如，如果你在同一個包里面有兩個管道，每一個都要求相同的參照數據集，每一個Lookup組件將緩存它自己的拷貝。在SQL Server 2008中，你可以將這個緩存保存到虛擬內存或永久的文件存儲。這意味著在相同的包里面，多個Lookup組件可以共享相同的緩存。你可以將這個緩存保存到一個文件并將它與其它包共享。這個緩存文件格式為了加快速度進行了優化，并且對它的訪問比從原始關系型數據源重新加載這個參照數據集要快幾個數量級。

在SQL Server 2008中，Lookup組件推出了不匹配緩存(miss-cache)特性。當這個組件配置為直接對數據庫進行查找時，不匹配緩存特性通過可選地將在參考數據集中的不匹配入口鍵值加載進緩存從而節省了時間。例如，如果這個組件從進來的管道得到值123，但是Lookup組件已經知道在參考數據集里沒有匹配入口，這個組件將不會再在參考數據集里查找123。這降低了到數據庫中的一個多余而又昂貴的旅程。這個不匹配緩存特性在某些場合下可以將性能提高40%。

其它對Lookup組件的改進之處包括：

◆優化的I/O路徑使得緩存加載和查找操作更快速。

◆更直接的用戶界面，簡化了Lookup組件的配置，特別是緩存選項。

◆輸入中不匹配至少參考數據集中的一個入口的記錄會被發送到不匹配輸出。錯誤輸出只處理錯誤，例如截斷。

◆在查找轉換中的查詢語句可以在運行時做更改，使得編程轉換更加靈活。

◆改進了信息和錯誤消息來幫助故障排除和性能分析。

下圖描述了一個使用這個新Lookup的場景。

 
圖6: Lookup場景

數據流1從一個定制源組裝了一個緩存連接管理器(Cache Connection Manager，CCM)，然后數據流2使用相同的CCM來組裝lookup的緩存。這個圖片還顯示了Lookup組件3個輸出的使用。

4.2 管道性能

在SQL Server 2008 SSIS 中，幾個線程可以一起協作進行在SQL Server 2005 SSIS中要求一個單獨線程自己進行的工作。這使你的ETL性能可以提高幾倍。

在SQL Server 2005 SSIS 中，管道并行是非常粗糙的。當用戶有一個簡單的包，其中具有一個或兩個執行樹時，只會使用一個或兩個處理器，并且這個包可能不會獲益于具有幾個處理器的多處理器機器。即便是用戶使用多點傳送將數據流邏輯上分割，一個多點傳送的所有輸出路徑頁屬于同一個執行樹，并且它們由SQL Server 2005 SSIS數據流任務連續執行。

為了獲得高級并行，在SQL Server 2008 SSIS 中的管道允許更多的并行處理，這意味著使用多處理器機器可以獲得更高的性能。

通過使用一個共享線程池，多點傳送的多個輸出可以同時執行。簡要的說，這個多點傳送提供了在每一個輸出上具有一個可用緩沖的能力，并且不只有一個緩沖(和一個可用線程)，這個能力提供給每一個輸出。你不需要使用“Union All”技巧作為一個平臺來推出更多的并行。

例如，假設你有一個包含具有四個輸出的多點傳送數據流。每一個輸出都流入一個聚合里。在SQL Server 2005 SSIS 中，同一時間只處理一個聚合。在SQL Server 2008 SSIS 中，這四個聚合可以并行處理。

下圖顯示了增強的SQL Server 2008管道并行是怎樣工作的。

 
圖7: 集成服務中改進的管道并行

#p#

5. 分析服務的改進

SQL Server 2008分析服務(SSAS)使用新的塊計算、寫回和可擴展的共享數據庫執行特性顯著地提高了查詢速度。管理能力還改進了備份更大規模數據庫的能力。

5.1 MDX查詢性能：塊計算

在SQL Server 2008 SSAS中改進的塊計算主要通過只作用于立方體空間的非null值從而加快了MDX查詢處理。它沒有花費時間評估null單元。子空間計算的主要思想通過與一個計算的“本地”逐個單元評估相比較可以很好的得出。假設一個計算RollingSum 計算了上一年和今年的銷售總和，而一個查詢是查找RollingSum 2005年所有產品的總和。

RollingSum = (Year.PrevMember, Sales) + Sales

SELECT 2005 on columns, Product.Members on rows WHERE RollingSum

這個計算的一個逐個單元評估過程如下圖所示。

 
圖8: 逐個單元評估例子

[2005, all products]的10個單元輪流評估。對于每一個，我們回到上一年，取得銷售值，并將它添加到今年的銷售里。這個方法有兩個明顯的性能問題。

首先，如果數據是稀疏的，那么即使是會返回一個null值的單元也會被計算。在這個例子里，計算除了Product3和Product6以外的任何一個單元都是種浪費。這個影響可能極大——在一個稀疏立方體種，被評估的單元數目可能會相差好幾個數量級。

其次，即使數據總的來說是密集的——意味著每一個單元都有一個值并且沒有浪費時間訪問空單元，也還是有重復的工作。每一個產品都重復做了相同的工作(例如獲得上一年成員、為上一年單元建立新的上下文、檢查遞歸)。將這個工作從評估每一個單元的內部循環中刪除將會使得更為高效。

現在假設使用一個子空間計算方法來執行相同的例子。首先，我們以自己的方式建立一個執行樹，確定應該填寫哪塊空間。假設我們需要為下面的查詢計算空間：

[Product.*, 2005, RollingSum]

假設有這個計算，這意味著我們必須先計算空間：

[Product.*, 2004, Sales]

接著這個空間：

[Product.*, 2005, Sales]

然后對這兩個空間應用‘+’操作符。

銷售是一個基本測量，所以我們簡單獲得存儲引擎數據將這兩個空間填寫在葉子節點，然后生成這個樹，應用這個操作符填寫根節點的空間。因此獲得了這個記錄(Product3，2004，3)以及這兩個記錄{ (Product3，2005，20)，(Product6，2005，5)}，并對它們應用了+操作符來生成結果。

 
圖9: 避免對NULL單元進行操作的塊計算例子

+操作符操作于空間，不是簡單的數量值。它結合兩個空間以生成一個包含每個空間中產品的空間，它的值是它們的總和。

我們只對可用于結果的數據進行操作。我們不打算對整個空間執行計算。

#p#

5.2 查詢和回寫性能

回寫操作的性能，以及對回寫數據的查詢，在SQL Server 2008分析服務中獲得了提高。在分析服務中的單元回寫是提供給終端用戶在葉子級或聚合級更新單元值的能力。單元回寫為每一個測量組使用一個特別的回寫分區，它存儲了最新的單元值和原始值之間的不同(delta)。當一個MDX查詢請求這個測量組的單元數據時，存儲引擎訪問所有分區，包括回寫分區，并將結果聚合以生成正確的單元值。

在SQL Server 2005和更早的版本中，分析服務要求回寫分區具有ROLAP存儲。這通常是單元回寫中發生性能問題的原因，因為ROLAP分區按需查詢關系型數據源以獲得它們的數據。在SQL Server 2008中，我們允許回寫分區使用MOLAP存儲。從壓縮MOLAP格式獲得回寫數據比查詢關系型數據源要快得多。因此，MOLAP回寫分區具有比ROLAP更好的查詢性能。這個性能改進的多少是很大不同的，并且取決于一些因素，包括回寫數據的大小和查詢本身。

MOLAP回寫分區還應該提高了單元回寫性能，因為服務器從內部發送查詢來計算回寫delta，而這些查詢很可能訪問回寫分區。注意，回寫事務提交可能會慢一些，因為服務器不只要更新回寫表，還必須更新MOLAP分區數據，但是這與獲得的其它性能相比就無關緊要了。

5.3 分析服務加強備份

在SQL Server 2008服務中你會發現其中的一個性能改進是新的備份存儲子系統。現在的備份存儲子系統已經重寫了，它使得可以得到更好的性能和可擴展性。這個改變對于你的應用程序來說是透明的——使用它不必改動代碼。

新的備份存儲子系統為分析服務備份文件推出了一個新的格式。這個文件名稱擴展名沒有改變。但是，內部的格式不同了，所以備份可以很好的升級到可以處理GB規模的數據庫。

SQL Server 2008分析服務備份完全向后兼容SQL Server 2005分析服務。它使得你可以恢復在SQL Server 2005分析服務中備份的數據庫。SQL Server 2008分析服務不具有以SQL Server 2005分析服務中所使用的舊格式來存儲備份的能力。

新的高性能備份存儲子系統允許客戶執行新的備份場景。而在以前你需要依靠不成熟的文件系統拷貝工具來備份大型數據庫，現在你可以使用與事務型系統集成在一起的內置備份子系統，并且可以與其它操作并行運行備份。

5.4 用于分析服務的可擴展共享數據

現在你可以就使用一個單獨的數據庫拷貝來升級你在許多小型服務器上的OLAP查詢工作負載。SQL Server 2008分析服務通過一個叫可擴展的共享數據庫(SSD)來支持這么做。

升級可以應用于很多場景和工作負載，例如處理、查詢、數據和緩存管理。對于分析服務來說，最常見的升級場景是響應不斷增加的并發用戶數量，擴展多個服務器上的查詢負載。這在過去是通過使用一個負載平衡解決方案來實現的，例如在多個服務器前面使用Microsoft Network Load Balancing (NLB)功能以及在服務器間復制數據。管理這樣的環境會遇到許多挑戰，而數據復制是主要的一個。可擴展的共享數據庫特性使得數據庫管理員可以將一個數據庫標記為只讀的，并將它從一個Storage Area Network(SAN)在多個服務器實例間共享，從而不再需要復制數據。這節省了磁盤空間，以及花費在拷貝數據上的時間。

下圖描述了一個典型的SSD配置。

 
圖10: 用于分析服務的可擴展共享數據庫

提高性能的一個可選解決方案是升級，用一個單獨的大型服務器替代多個小型服務器。升級的好處是在一個更大型的機器上，單獨的查詢可以處理的更快。但是通過SSD使用升級可以為你節省硬件(假設每個處理器成本更低)，并仍然滿足你對許多多用戶工作負載的需求。此外，SSD允許你擴展為比可以用在一個單獨的大型服務器上更多的處理器。

可擴展的共享數據庫特性包含三個邏輯部分：

◆只讀數據庫：允許將一個數據庫標記為只讀的

◆數據庫存儲位置：允許一個數據庫放在服務器數據文件夾外

◆附加/分離數據庫：允許從任何UNC路徑附加或分離數據庫

這些特性一起使得可以查詢升級場景。然而，每一個特性都是獨立的，并且還有查詢擴展以外的用法。

用于分析服務特性的SSD與在SQL Server 2005關系型數據庫中推出的SSD特性工作方式類似。

#p#

6. 報表服務的改進之處

SQL Server 2008報表服務(SSRS)提供了性能、擴展和設計改進，使得它可以很好的滿足你的企業報表需求。在這里我們著重介紹兩個主要的可擴展性改進。

6.1 報表可擴展性

SQL Server 2008報表服務報表引擎與之前版本相比具有一個較大的提高，它可以渲染比以前大得多的報表。盡管這不是數據倉庫的一個重要提高(它在操作性報表中也可以使用)，但是它在一些數據倉庫場景中是非常有用的。如果你創建具有幾百甚至上千頁的報表，那么SQL Server 2008報表服務可以幫助你更快地渲染報表。而且，在相同的硬件配置下，可以渲染的最大報表規模顯著地增加了。

6.2 服務器可擴展性

SQL Server 2008報表服務不是運行在IIS內部。它可以管理它自己的內存，并具有它自己的內存限制。這使得你可以配置內存設置以便SSRS可以更加高效地與其它服務運行在同一臺機器上，例如SQL Server。

7. 總結

QL Server 提供給你在數據倉庫方面所需要的所有東西。在2008版本里，它進一步擴展，比之前版本都更加可以滿足最大規模企業的需求。正如這篇文章里所描述的許多數據倉庫改進之處，它與之前的版本相比改進了很多。你將看到最重要的改變是用于數據倉庫建設、關系型查詢處理、報表和分析的、改進的可擴展性。

【編輯推薦】

1. 動態數據倉庫漸興起 推動BI走到前端
2. 輕松掌握數據倉庫開發
3. BI技術在全面預算管理中的研究
4. CRM中商業智能之數據挖掘全視圖
5. 走近數據庫前沿技術——集群