Fast Track Data Warehouse Reference Guide for SQL Server 2012

SQL Server 2012 快速追蹤資料倉儲參考指南

SQL Server 技術文件

作者：Eric Kraemer、Mike Bassett、Eric Lemoine、Dave Withers

技術審稿者：Claude Lorenson、Susan Price、Ralph Kemperdick、Henk van der Valk、Alexi Khalyako、Oliver Chiu

發行日期：2012 年 3 月

適用於：SQL Server 2012

摘要：本文定義了何謂參考組態模型 (又稱為快速追蹤資料倉儲)，該模型使用資源平衡法實作對稱式多處理器 (SMP) 為主的 SQL Server 資料庫系統架構，以提供經過驗證的資料倉儲工作負載效能和延展性。快速追蹤資料倉儲參考架構的目標就是要在 SQL Server 資料處理能力與實現的元件硬體輸送量之間，達到理想有效的資源平衡狀態。

著作權

本文件是以原本的形式提供。本文件中所表達的資訊和觀點，包括 URL 及其他網際網路網站參考資料，如有變更恕不另行通知。您應自行承擔使用本文件的風險。

本文件不會為您提供任何 Microsoft 產品的任何智慧財產權的任何法律權限。您可以複製及使用本文件，但僅限組織內部參考用途。

© 2012 Microsoft. 著作權所有，並保留一切權利。

目錄FTDW 變更記錄6簡介6適用對象6快速追蹤資料倉儲6快速追蹤7價值主張7方法7整體元件架構7工作負載最佳化方法8經過驗證的 SQL Server 快速追蹤參考組態9摘要9FTDW 工作負載9資料倉儲工作負載模式9工作負載評估10質化的資料倉儲工作負載屬性12選擇 FTDW 參考組態13選項 1：基本評估13步驟 1：評估客戶使用案例13步驟 2：選擇一個已發行的 FTDW 參考架構15選項 2：完整評估15程序概觀15步驟 1：評估客戶使用案例15步驟 2：建立評估度量標準16步驟 3：選擇快速追蹤資料倉儲參考架構17選項 3：使用者定義的參考架構17步驟 1：定義工作負載17步驟 2：建立元件架構基準18選擇 FTRA 摘要18FTDW 標準組態19硬體元件架構19元件需求和組態20應用程式組態21Windows Server 2008 R221SQL Server 2012 Enterprise22儲存體系統23FTDW 的 SQL Server 最佳作法27資料架構28資料表結構28資料表資料分割29索引29xVelocity 記憶體中資料行存放區索引30資料庫統計資料31壓縮32管理資料片段33檔案系統片段33多個檔案群組35載入資料35累加式載入36資料移轉38基準和驗證40執行基準 FTDW 驗證41使用 SQLIO 測試基準41執行快速追蹤資料庫效能評定44計算 MCR45計算 BCR46發行的 FTDW 參考架構49結論49附錄50FTDW 系統調整大小工具50驗證使用者定義的 FTRA51綜合 I/O 測試51使用 SQLIO 產生測試檔案51工作負載測試54測量伺服器的 MCR (選擇性)54測量工作負載的 BCR54影響查詢使用率的因素58

FTDW 變更記錄

下表提供《快速追蹤資料倉儲參考指南》版本發行的重大變更或更新清單。

說明

版本

注意事項

位置

SQL Server 2012 新增項目

4.0

SQL Server 最佳作法其他文件連結

重要事項

SQL Server 2012 新增項目

4.0

基準和驗證

注意

SQL Server 2012 新增項目

4.0

記憶體需求

RAM

SQL Server 2012 新增項目

4.0

xVelocity 記憶體最佳化的資料行存放區索引

資料行存放區索引

SQL Server 2012 新增項目

4.0

固態儲存體

固態

SQL Server 2012 新增項目

4.0

驗證和資料行存放區索引

驗證

SQL Server 2012 新增項目

4.0

基準 I/O 的驗證

SQLIO

表 1：變更記錄

簡介

本文定義了 SQL Server 快速追蹤資料倉儲 (FTDW) 方案的元件架構和方法。採用此方法後，即可確知為達到及維持許多資料倉儲工作負載的現成效能基準，您所需要的基本 Microsoft SQL Server 資料庫系統架構 (包括軟體和硬體)。

適用對象

本文的目標對象包含有興趣針對符合 FTDW 的 SQL Server 工作負載，選擇標準、經證實之系統架構的 IT 規劃人員、架構設計人員、資料庫管理員及商業智慧 (BI) 使用者。

快速追蹤資料倉儲

SQL Server 快速追蹤資料倉儲方案提供了基本方法和具體範例，協助您針對資料倉儲工作負載部署平衡的硬體和資料庫組態。如需詳細資訊，請參閱本文的＜FTDW 工作負載＞一節。

平衡是 SQL Server 安裝之主要系統元件的量值，這些元件包括儲存體、伺服器、儲存體網路、資料庫及作業系統。上述每個元件都會調整至最佳組態。這麼做的目標就是為了在 SQL Server 資料處理能力與硬體元件資源之間，達到立竿見影的平衡效果。在理想情況下，您的組態將包含基本系統硬體配置，可滿足資料倉儲工作負載的儲存和效能需求。

快速追蹤

SQL Server 快速追蹤品牌可找出符合 FTDW 參考架構 (FTRA) 原則的元件硬體組態。對於每個 FTRA，我們都會清楚列明工作負載，以及一組核心組態、驗證和資料庫最佳作法方針。以下是快速追蹤方案的主要原則：

· 工作負載特定的基準。系統設計和組態皆根據實際的並行查詢工作負載。

· 詳細且經驗證的硬體元件規格。

· 資料庫功能與主要硬體資源之間的元件架構平衡。

價值主張

下列原則就是 FTDW 價值主張的基礎：

· 預先打造主要系統元件之間的完美平衡。如此可將風險降到最低，避免花費過多成本購置永遠用不到的 CPU 或儲存體資源。

· 可預測的現成效能。快速追蹤組態是依據容量所建立，而此容量已符合 SQL Server 應用程式處理所選伺服器和工作負載的能力。

· 以工作負載為中心。FTDW 方法不是一體通用的資料庫組態方法，此方法會特別針對資料倉儲使用案例進行調整。

方法整體元件架構

SQL Server FTDW 參考架構提供一個實用架構，可用以平衡資料庫系統架構的主要元件之間的複雜關係。此架構通常稱為「堆疊」，從 圖 1 可看到此元件架構的樣貌。

圖 1：快速追蹤資料庫元件架構範例

堆疊的每個元件都是一個連結，負責將處理 SQL Server 資料所需的一系列作業連結起來。將堆疊當做整合系統來評估，即可獲得建立每個元件之實際頻寬的基準。如此可確保個別元件提供足夠的輸送量，以符合 SQL Server 應用程式處理指定堆疊的能力。

工作負載最佳化方法

為達到最佳的資源平衡，不同的資料庫應用程式工作負載所需的元件架構可能差別相當大。例如，小型要求、查閱式線上交易處理 (OLTP) 工作負載，以及需要大量掃描、大型要求的分析資料倉儲之間的對比就是典型的範例。OLTP 使用案例會編製大量索引，因此擷取資料集當中少數資料列時可降低延遲情況，這些資料集通常包含很少的記錄資料量。這些資料庫作業類型會產生大量的磁碟讀寫頭移動，並產生傳統隨機 I/O 掃描模式。分析使用案例 (例如資料倉儲) 包含的資料要求可能大上許多。因為循序磁碟掃描可帶來總輸送量提升，分析使用案例更可大大受益。

對於這些對比使用案例而言，平衡元件堆疊的影響非常重要。與相同硬體的循序掃描速率相較下，每個現代 SAS 磁碟機的平均隨機 I/O 掃描速率可能慢 10 倍。快速追蹤資料倉儲工作負載強調達到一致的高 I/O 掃描速率 (以 MB/s 為單位)，有別於集中在每秒作業數目 (以 IOPS 為單位) 的傳統作法。

但只要清楚定義客戶工作負載的屬性，即可解決因工作負載巨大差異所帶來的挑戰。透過 SQL Server 快速追蹤工作負載包含屬性的質化清單，常見的資料庫應用程式使用案例可因此獲得獨一無二的定義。此外，每個工作負載都會以量值來表示，包括標準基準查詢。工作負載特定的基準可用來驗證資料庫組態、最佳作法及元件硬體建議。

經過驗證的 SQL Server 快速追蹤參考組態

所有發行的快速追蹤參考架構都經過驗證，完全符合本參考指南中所提供的原則和方針。本文稍後章節將陸續說明此程序的範例。

摘要

本參考指南所描述的 SQL Server FTDW 規格是以工作負載為中心，其中各元件都呈現平衡狀態。此方法主張一體通用的佈建規模對於許多資料庫使用案例而言既沒效率又昂貴。隨著商務需求越來越複雜，加上快速擴充的資料量，您需要更實際可行的方法。透過呈現對症下藥的參考架構、軟硬體元件的基準及目標明確之工作負載的組合，本文提供了一個實用方法助您達成平衡的元件架構。

FTDW 工作負載資料倉儲工作負載模式

關於資料倉儲，一般經常問到的問題都源自於這類模式需要存取大量資料。資料倉儲必須支援來自廣泛對象的各種查詢 (例如：財務、行銷、營運及研究小組)。

為了克服傳統資料倉儲系統的限制，組織長久仰賴傳統的 RDBMS 最佳化技術 (例如建置索引、預先彙總資料及限制較低層級資料的存取次數)。即使各維護期間排得很寬鬆，這些方法所衍生的維護負擔通常還是讓人備感壓力。隨著資料倉儲漸臻成熟且需服務的目標對象日益增多，想要針對不同使用案例進行最佳化無疑變得更具挑戰性，特別是在資料延遲抵達或資料更正的情況下更是如此。

面對這項挑戰，一個常見解決方法是直接新增磁碟機。因此，我們常常會看到數百個磁碟用來支援規模沒那麼大的資料倉儲，為的只是要克服效能限制，將搜尋式 I/O 基礎結構對應至掃描式工作負載的 I/O。這在傳統搜尋最佳化的大型共用存放區域網路 (SAN) 環境很常見。許多儲存體 I/O 參考模式和技術都會促進隨機 I/O 存取，但對於需要執行大量掃描的資料倉儲工作負載而言，這樣只是徒增磁碟延遲並降低整體儲存體子系統的輸送量。

快速追蹤資料倉儲則是採用不同的方式來將資料倉儲工作負載最佳化。透過有效率的磁碟掃描 (而非搜尋) 存取模式調整資料庫檔案和組態，個別磁碟所能達到的效能可高出好幾倍。每個磁碟的效能因此提升，連帶著也不再需要動用過多的磁碟，即可產生足夠 I/O 輸送量，讓 SQL Server 處理指定工作負載資料的能力得以完全發揮。此外，您還可以避免使用某些以索引方式最佳化的技術，有效改善磁碟搜尋效能。

工作負載評估

分析 FTDW 系統的工作負載時，請務必考量本文所述之作法和系統組態的適用性。資料倉儲需求會隨客戶和特定需求 (例如資料庫複寫) 而有所不同，因此可能不會適用於所有 FTDW 設計系統。此處概述此工作負載評估類型的主要初始準則。

掃描密集

資料倉儲工作負載的查詢經常掃描大量資料列。因此，磁碟掃描效能的優先順序變得越來越高，與強調磁碟搜尋時間的交易工作負載正好相反。在將硬體和資料庫軟體元件最佳化時，FTDW 參考架構主要會優先考量磁碟掃描效能。這會使循序磁碟讀取更有效率，進而提升每個磁碟機的磁碟 I/O 輸送量。

靜態

資料在寫入之後，很少會變更。您應該謹慎管理 DML 作業 (例如 SQL 更新)，因為該作業會移動與相同資料庫資料表相關的頁面，使資料無法連續。通常造成這類變動的工作負載可能不適合 FTDW。建議您對發生變動的位置進行定期維護，以將分散程度降到最低。

少量索引

新增非叢集索引通常可提升查閱一或幾筆記錄的效能。如果將非叢集索引套用至要擷取大量資料列的資料表，會導致增加隨機磁碟搜尋作業數目，進而降低整體系統效能。維護索引也會增加大量資料管理負擔，進而危及服務等級合約 (SLA) 和即時載入資料庫的能力。

相反地，循序掃描速率可能會比隨機存取速率高上許多倍 (10 倍以上)。減少隨機搜尋使用次數並產生次要索引的系統，通常會保持較高的平均 I/O 速率。這表示儲存體 I/O 資源的使用情形更有效率，並更能預測大型掃描查詢的效能。

FTDW 方法能針對目標工作負載特性指定適用的資料庫最佳化技術。說到支援高效掃描式磁碟 I/O 的資料結構，叢集索引和定界分割是兩個首選範例。建議您在 FTDW 環境中使用這兩種方法作為資料架構最佳化的主要工具。

資料分割對齊

FTDW 工作負載的一個常見特徵是能夠利用 SQL Server 資料分割。資料分割可簡化資料生命週期管理，並協助在此期間中大幅縮減分散的資料片段。此外，大型掃描的查詢模式可利用定界分割限定條件，大幅降低資料表掃描的大小，而不需要犧牲片段或磁碟 I/O 輸送量。

其他考量

評估資料庫工作負載期間，您還應該考慮下列其他事項：

· 少量索引資料庫最佳化策略的實作和管理是 FTDW 工作負載的基本需求。

· 資料倉儲內應該只需要維護非常少量的資料片段。這表示：

· 最主要的片段類型能以片段大小為測量單位。一個片段表示 8K 資料庫頁面的連續配置。

· 當您透過新增儲存體來擴充伺服器時，必須採用符合本文方針的方式來重新擴展所有攸關效能的資料表。

· 實作易變的資料結構 (例如包含資料列層級定期更新活動的資料表) 可能需要經常的維護 (例如重組或索引重建)，才能降低資料分散程度。

· 分批載入叢集索引資料表，而其中叢集索引鍵識別碼又與現有範圍重疊時，常常會造成資料斷斷續續。建議您根據本參考指南所提供的最佳作法，對此謹慎監視及管理。

· 資料倉儲對於不同對象可能有不同意義。您應該根據 FTDW 工作負載屬性，謹慎評估客戶需求。

質化的資料倉儲工作負載屬性

您可以透過下列與資料庫作業相關之主題區域的內容，來定義 FTDW 工作負載：

· 使用者需求和存取模式

· 資料模型

· 資料架構

· 資料庫最佳化

下表摘要說明資料倉儲工作負載屬性，並透過比較 OLTP 或操作資料存放區 (Operational Data Store，ODS) 工作負載來提供對比。

屬性

工作負載相似性：

資料倉儲

OLTP/ODS

使用案例說明

· 主要為讀取 (90%-10%)

· 更新通常僅限於資料品質需求

· 大量插入

· 整體查詢並行處理需求屬於中低程度，尖峰並行查詢要求範圍從 10-30 個不等

· 並行查詢輸送量主要環繞在分析和報告需求

· 大範圍掃描及/或彙總

· 複雜查詢 (篩選、聯結、群組依據、彙總)

· 平衡的讀取-更新比例 (60%-40%)

· 並行查詢輸送量主要環繞在操作需求

· 微調插入及更新

· 高交易輸送量 (例如 10s K/sec)

· 整體使用者並行處理需求為中高程度，尖峰並行查詢要求範圍為 50-100 以上

· 通常是很短的交易 (例如非常少量的離散資料列查閱)

資料模型

· 高度正規化的集中式資料倉儲模型

· 為支援報告需求的非正規化通常會由 SQL Server Analysis Services 等 BI 應用程式提供

· 裝載於資料庫上的維度資料結構具有相對較低的並行處理需求，以及大量的分析要求

· 大範圍掃描是常見的情況

· 隨選分析使用案例

· 高度正規化的操作資料模型

· 為支援決策的經常性非正規化；具有高並行處理能力及低度延遲的離散查閱

· 資料記錄保留有限

· 為支援作業事件決策制定，而從其他來源系統擷取非正規化資料模型

資料架構

· 大量使用堆積資料表結構

· 大型資料分割資料表包含叢集索引，可支援限制範圍的掃描作業

· 非常大的事實資料表 (例如數百 GB 至數 TB 之譜)

· 資料大小很大 (例如數百 TB 至 PB 之譜)

· 很少使用堆積資料表結構

· 支援詳細記錄查閱的叢集索引資料表結構 (每個要求處理一至幾個資料列)

· 較小的事實資料表 (例如小於 100 GB)

· 資料大小相對較小 (例如數 TB)

資料庫最佳化

· 很少使用次要索引 (即稍早所述的少量索引)

· 資料分割很常見

· 大量使用次要索引最佳化

表 2：資料倉儲工作負載屬性

選擇 FTDW 參考組態

想使用本文所述的 FTDW 方法，一般可從三方面著手。前兩個方法是針對資料倉儲，特別使用已發行且相符的快速追蹤參考架構。這兩個方法可讓您選取已隨 FTDW 方案發行的預先設計系統。第三種方法則是將核心快速追蹤方法視為指導方針，建立使用者定義的資料倉儲系統。若要採用最後這個方法，您需要在購買或部署前進行詳細的工作負載分析和系統效能評定。您必須非常熟悉企業伺服器、儲存體組態及 SQL Server 資料庫最佳化等領域，才可使用此方法。

選項 1：基本評估

在此案例中，客戶已屬意一種 FTDW 參考組態或具有替代方法，藉此判斷伺服器和 CPU 需求。如果您使用此選項，則不需要執行完整平台評估 (亦即概念的證明)。

步驟 1：評估客戶使用案例

快速追蹤資料倉儲參考組態不是一體通用的軟硬體組態，而會根據資料倉儲工作負載的特性量身打造。選擇組態的第一個步驟是找出這些特性；一開始請先檢查客戶需求和使用模式等主要部分。

工作負載

FTDW 工作負載定義提供了兩個使用案例評估重點。第一個重點是一組定義工作負載主要元素的核心原則，因為工作負載與 SQL Server 效能息息相關。任何衝突可能表示目標工作負載不適合 FTDW 參考架構，因此您應該根據指定的使用案例謹慎評估這些原則。

工作負載的第二個元件為目標使用案例的一般描述。除了做為評估工作負載適用性的理想起點，這個元件更提供了使用案例的實用扼要描述。

工作負載評估

下列清單概述了客戶工作負載評估的基本程序。您可將此質化評估視為指導方針：

1. 定義目標工作負載需求。比較及比對 FTDW 工作負載屬性。如需詳細資訊，請參閱本文的＜FTDW 工作負載＞一節。

2. 評估 FTDW 最佳作法。您應該根據目標使用案例和作業環境，評估資料庫管理、資料架構及系統最佳化相關的作法。

制定決策

此工作負載評估的目標，是為了確保能夠制定充分旁徵博引的決策，進而選出經驗證的 FTDW 參考架構。事實上，大多數資料倉儲案例都混合了與 FTDW 工作負載相關的符合和衝突屬性。此處列出與快速追蹤參考組態有極高相似性的高優先順序工作負載屬性。您應該謹慎評估與這些屬性直接衝突的主要客戶使用案例，因為這些衝突點可能會導致這個方法在此使用案例中毫無用武之地。

工作負載

下列工作負載屬性具有高優先順序：

· 關鍵工作負載的特徵是具備大量掃描的資料存取模式 (亦即可從循序資料位置中獲益的模式)。一般而言，每個查詢要求需要讀取數萬至數百萬 (或以上) 的資料列。

· 與一般 OLTP 工作負載相比，具備較高的資料容量以及較低的並行處理需求。

· 資料變動程度低。經常性更新/刪除 DML 活動應限制在整體資料倉儲量的一小部分。

資料庫管理

包括資料庫管理、資料架構 (資料模型和資料表結構) 及資料整合作法：

· 少量索引的資料分割資料架構。

· 透過適當的載入和 ETL 策略以及定期維護，謹慎管理資料庫片段。

· 可預測的資料成長需求。FTDW 系統經過預先建置，可提供完全平衡的容量。因此擴充儲存體時，您需要移轉資料。

步驟 2：選擇一個已發行的 FTDW 參考架構

客戶在根據預算或經驗執行簡單評估時，可能心中已有屬意的伺服器。或者，對於分析頻寬需求所依據的工作負載容量或現有系統，客戶可能已有清楚的想法。不論是哪一種情況，您都不需要在 FTDW 基本評估中執行完整平台評估。相反地，您可以選取與客戶預估需求相符的 FTDW 組態。

選項 2：完整評估

快速追蹤參考架構提供了配合已定義客戶工作負載需求的硬體元件組態。下列方法能協助您透過簡化的方法選擇資料庫元件架構，確保使用案例需求、效能及延展性之間都能獲得立竿見影的絕佳平衡表現。我們假設採用此方法的讀者都已具備資料庫系統架構和資料倉儲部署的高度專業知識。在此程序中，您通常需要藉助於快速追蹤夥伴及 Microsoft 技術銷售資源。

程序概觀

下列處理流程摘要說明 FTDW 完整評估的選取程序：

1. 根據目標使用案例評估快速追蹤工作負載屬性。

2. 識別客戶使用案例的伺服器及/或頻寬需求。開始評估之前，您必須選擇一個已發行的 FTDW 參考組態。

3. 識別客戶工作負載需求的代表性查詢。

4. 計算 SQL Server 用於查詢的基準使用率 (Benchmark Consumption Rate，BCR)。

5. 計算所需的使用者資料容量 (User Data Capacity，UDC)。

6. 根據發行的最大 CPU 使用率 (Maximum CPU Consumption Rate，MCR) 及額定容量比較額定 BCR 和 UDC，以取得相符的快速追蹤參考架構。

以下詳細說明完整評估處理流程的個別步驟。

步驟 1：評估客戶使用案例工作負載評估

此程序與＜選項 1：基本評估＞的程序相同。

選取 FTDW 評估硬體

開始完整系統評估之前，您必須選擇及部署已發行的 FTDW 參考組態以進行測試。您可以從數個方法中進行選擇，找出適當的參考組態。以下是常見的方法：

· 預算。在可用預算內，客戶選擇購買最高容量的系統及/或最高效能的系統。

· 效能。在符合需求的選項中，客戶選擇購買效能最高的系統。

· 內部分析。此決策會以客戶在現有硬體上執行的工作負載分析為依據。

· 特定分析。FTDW 調整大小工具提供計算 FTDW 系統需求的基本方法，此方法是以目標資料庫工作負載的基本假設為依據。此試算表工具可從下列網址下載：http://download.microsoft.com/download/D/F/A/DFAAD98F-0F1B-4F8B-988F-22C3F94B08E0/Fast%20Track%20Core%20Calculator%20v1.2.xlsx。

步驟 2：建立評估度量標準

下列三個度量標準對於完整 FTDW 評估而言很重要，並構成硬體評估的主要決策準則：

· 最大 CPU 核心使用率 (MCR)

· 基準使用率 (BCR)

· 所需的使用者資料容量 (UDC)

如需計算這些度量的詳細資訊，請參閱本文的＜基準和驗證＞一節。

MCR

此度量可針對特定伺服器和 CPU 的組合，測量標準查詢和資料集的最大 SQL Server 資料處理速率。此度量會以每個核心的速率呈現，當記憶體快取進行查詢式掃描時即記錄一次。MCR 是快速追蹤系統設計的初始起點，代表著伺服器、CPU 及工作負載所需的最大估計 I/O 頻寬。由於 MCR 只需要最低本機儲存體及資料庫結構描述，即可估計指定 CPU 的潛在輸送量，因此可作為初始設計指導方針。必須強調的是，MCR 可作為系統設計的起點，但不是系統效能的量值。

BCR

透過監測對 FTDW 工作負載有決定性影響的一組查詢進行測量，我們可得到 BCR 資訊。BCR 會計算磁碟和快取的讀取頻寬總計，而不是和 MCR 計算一樣僅限於快取。透過評估一組符合客戶工作負載模式的查詢，BCR 有助於未特定客戶使用案例量身打造專屬的基礎結構。或者，在採用夥伴驗證 FTRA 的情況下，我們會使用一組基準查詢確保系統的設計適合壓力高張的工作負載。總而言之，BCR 可在並行工作負載下，實際測量針對大量資料使用多個查詢的資料處理能力。

使用者資料容量

這是 SQL Server 資料庫的預期資料庫容量。快速追蹤使用者資料容量能說明載入後的資料庫壓縮情況，並呈現可載入快速追蹤系統但尚未壓縮的使用者資料檔案或資料流的估計數量。FTDW 使用的標準壓縮比為 3.5:1。

請注意，如需在初始部署之後擴充任何儲存體，您都可能需要移轉資料，才能有效地在新的資料庫檔案位置之間等量分割現有的資料。因此，在選擇適當的參考架構時，請務必考量未來預期的資料庫成長和平均系統壽命。

步驟 3：選擇快速追蹤資料倉儲參考架構

計算 BCR 之後，可將其與每個發行之 FTRA 的快速追蹤夥伴所提供的已發行 MCR 和額定容量進行比較。如需我們的夥伴的詳細資訊，請參閱＜快速追蹤資料倉儲＞(http://www.microsoft.com/sqlserver/en/us/solutions-technologies/data-warehousing/fast-track.aspx)。

您可以使用 BCR 度量作為一般參考點，根據已發行組態評估測試/評估系統的結果。您的客戶可以 BCR 資料作為起點，選擇最適合測試結果的快速追蹤選項。

選項 3：使用者定義的參考架構

此方法會利用 FTDW 方法，並根據特定工作負載或一組硬體量身打造一套專屬系統。您必須非常了解 SQL Server 及其所執行的硬體元件，才能採用此方法。下列步驟概述了開發符合 FTDW 原則之使用者定義參考架構的一般方法。

步驟 1：定義工作負載

了解目標資料庫使用案例是 FTDW 組態的核心，且此原則適用於本文所提供之指引的所有自訂應用。您可以使用 FTRA 指引 (特別是工作負載主題) 作為參考模型，將工作負載評估併入元件架構設計中。

步驟 2：建立元件架構基準

下列架構提供一個基本架構，以針對預先定義的工作負載開發參考架構：

1. 建立所選伺服器和 CPU 的最大 CPU 核心使用率 (MCR)。使用本文＜基準和驗證＞一節所述的方法計算 MCR。您也可以針對 FTDW 組態使用發行的額定 MCR。一般而言，相同系列的 CPU 具有類似的 SQL Server 資料庫 CPU 核心使用率。

2. 使用 MCR 值估計儲存體和儲存體網路需求，並建立初始系統設計。

3. 取得以初始系統設計為基礎的測試系統。在理想情況下，此為指定的完整組態。

4. 建立基準使用率 (BCR)。根據工作負載評估，識別查詢或一組代表性查詢 (理想情況下)。請依照本文＜測量工作負載的 BCR＞一節所述的作法執行。

5. 根據結果調整系統設計。

6. 建立最終伺服器和儲存體組態。

步驟 3：系統驗證

系統效能評定的目標應該是步驟 2 中指定之硬體元件組態的組態和輸送量驗證。如需此程序的詳細資訊，請參閱本文的＜驗證使用者定義的 FTRA＞一節。若要驗證系統，請執行下列步驟：

1. 根據既定效能需求評估元件輸送量。如此可確保實際系統輸送量符合預期。

2. 透過重建至最終組態及執行最終效能評定，仔細驗證系統輸送量。最終 BCR 通常應達到系統 MCR 的 80% 或以上。

選擇 FTRA 摘要

下表摘要說明了三種 FTRA 選項。

選項

優點

缺點

基本評估

· 系統設定和取得非常快 (幾天至幾週)

· 將設計和評估成本降到最低

· 不需具備高深的基礎結構技能

· 可能會超出指定的儲存體或未達到指定的 CPU

完整評估

· 根據預期的工作負載量身打造預先定義的參考架構

· 可能節省硬體成本

· 客戶對方案的信心增加

· 評估費時費力 (幾週至幾個月)

· 必須對目標工作負載非常了解

使用者定義的參考架構

· 可能重複使用現有的硬體

· 可能併入最新的硬體

· 精細量身打造的系統非常符合使用案例需求

· 此程序需要幾個月

· 需要具備深厚的基礎結構專業知識

· 需要具備深厚的 SQL Server 專業知識

表 3：不同評估選項的比較

FTDW 標準組態硬體元件架構

目前的 FTDW 參考架構是以專用儲存體組態為基礎。目前發行的選項包括交換式 SAN、直接附加的 SAN、直接附加的 SAS、SAS-RBOD 和 iSCSI。磁碟 I/O 輸送量是透過使用獨立、專用的儲存裝置和處理器來達成。各個快速追蹤廠商會發行其他詳細資料和組態。圖 2 描述了以 SAN 存放裝置為基礎之 FTDW 參考架構所組成的元件層級建置組塊。

圖 2：2 個通訊端、12 個核心伺服器的儲存體組態範例

元件需求和組態伺服器記憶體

RAM 總計：FTRA 的 RAM 配置會根據目標為平衡最大邏輯輸送量 (在一段時間內從磁碟和緩衝區讀取的總頁數) 與 CPU 使用量的基準結果。表 4 列出 SQL Server 2012 參考架構的建議記憶體配置。此處提供的記憶體最大值不是固定限制，而是代表成功驗證之系統的平均值。

伺服器大小

最小記憶體

最大記憶體

1 個通訊端

64 GB

128 GB

2 個通訊端

128 GB

256 GB

4 個通訊端

256 GB

512 GB

8 個通訊端

512 GB

768 GB

表 4：SQL Server 2012 的建議記憶體配置

評估系統記憶體需求時，您也必須注意下列考量：

· 從快取查詢：對於從快取提供大部分查詢的工作負載而言，如果 RAM 配置能隨工作負載成長，整體效能就能因此提升。

· 雜湊聯結和排序：對於仰賴大型雜湊聯結或執行大型排序作業的查詢而言，具有大量實體記憶體有助於提升效能。如果記憶體較小，這些作業會溢出到磁碟並大量使用 tempdb，導致伺服器上的各資料磁碟機產生隨機的 I/O 模式。

· 載入：如果無法在可用記憶體中處理大量插入，大量插入也會使用 tempdb 進行排序作業。

· xVelocity 記憶體最佳化的資料行存放區索引：對於大量使用資料行存放區索引查詢計畫的工作負載，使用表 4 所列之範圍較高的記憶體集區可提高執行效率。

光纖通道 SAN

HBA – SAN：所有 HBA 和 SAN 網路元件會依品牌和機型而些微不同。此外，儲存裝置輸送量可能會受到 SAN 組態和 PCIe 匯流排功能的影響。此建議是一般方針，且與 FTDW 參考組態開發期間所執行的測試一致。

如果使用分區，區域中只應存在快速追蹤所使用的通訊埠。詳細的 FC 網路拓撲和組態會記載於每個快速追蹤夥伴所提供的《技術設定指南》中，且每個已發行的 FTRA 會有特定的網路拓撲和組態。

多重通道的 I/O (MPIO)：您應該設定 MPIO。裝載於專用儲存體陣列上的每個磁碟區都應該具備至少一個使用中的路徑。

「以子集循環配置資源」是快速追蹤組態所使用的預設原則，但夥伴參考架構很少使用此原則，因為 FTDW 夥伴工程團隊會為您找出更適合的組態。夥伴專屬的 DSM 及/或文件通常規定不同的設定，因此您在設定前應仔細檢閱。

儲存體

本機磁碟：雙磁碟 RAID1 陣列是 Windows Server 和 SQL Server 安裝的最低配置。您應該為虛擬 RAM 和分頁需求配置足夠的磁碟空間。一般而言，可用磁碟空間應大於 250 GB 或為系統 RAM 的 1.5 倍。其餘磁碟組態則取決於使用案例和客戶偏好設定。

邏輯檔案系統：基於快速追蹤系統包含許多磁碟區數目，建議作法是將 LUN 掛接到 Windows 中的掛接點資料夾路徑，而不是磁碟機代號。

了解哪個 Windows 作業系統磁碟機指派代表儲存裝置中的哪個 LUN (磁碟區)、RAID 磁碟群組及 Windows Server 掛接點，這樣也很有用處。將 LUN 掛接到 Windows 資料夾時，可採用掛接點和磁碟區的命名配置。如需裝置命名配置的詳細資訊，請參閱快速追蹤夥伴技術設定指引。

您可以使用廠商特定的工具來達成建議的磁碟區命名配置。如果找不到適當的工具，您可以透過儲存體陣列一次提供一個磁碟給 Windows，同時指派磁碟機名稱以確保實體對邏輯的拓撲正確無誤。

實體檔案系統：如需詳細資訊 (包括詳細說明)，請參閱本文的＜應用程式組態＞一節。

儲存裝置組態：除非快速追蹤夥伴的技術文件另有說明，否則所有裝置的設定會保留其預設值。檔案系統組態的 FTDW 規格需要允許 RAID 分組和 LUN 指派之特定組態的儲存裝置。進行任何 FTDW 參考組態硬體替代評估或自訂硬體評估時，您都應該將此需求列入考量。

應用程式組態Windows Server 2008 R2

除非另有說明，否則應使用 Windows Server 2008 R2 Enterprise 作業系統的預設設定。請確定已套用最新 Service Pack 及所有重大更新。許多參考架構都需要多重通道的 I/O 功能。如需詳細 MPIO 組態的詳細資訊，請參閱快速追蹤夥伴之指定參考架構的技術設定指南。請確認將 Windows Server 2008 R2 安裝為應用程式伺服器角色，以確保具有適當的 .NET Framework 安裝和預設值。

SQL Server 2012 Enterprise啟動選項

您必須將 -E 新增至啟動選項。如此一來，當資料庫資料表成長時，每個檔案中配置給資料庫資料表的連續範圍數目也會隨著增加，進而改善循序磁碟存取效能。如需此選項的詳細資訊，請參閱 Microsoft 知識庫文章 329526 (機器翻譯) (http://support.microsoft.com/kb/329526)。請務必確認 -E 選項在啟動資料庫時已生效。此選項區分大小寫和格式。選項前後若加上空格會妨礙初始作業正常運作。

您也應該將 -T1117 新增至啟動選項。在啟用自動成長時，此追蹤旗標可確保檔案群組中的所有檔案都會平均成長。對資料庫檔案成長而言，標準的 FTDW 建議是預先配置，而不是自動成長 (tempdb 除外)。如需詳細資訊，請參閱本文的＜儲存體組態詳細資料＞一節。

啟用 [鎖定記憶體中的分頁] 選項。如需詳細資訊，請參閱＜如何：啟用鎖定記憶體中的分頁選項＞(http://go.microsoft.com/fwlink/?LinkId=141863)。

您應該根據個別情況評估是否使用 -T834。此追蹤旗標可提高許多資料倉儲工作負載的輸送量速率。採用此旗標後，SQL Server 緩衝集區的記憶體中即會啟用大型分頁配置功能。如需此追蹤旗標及其他追蹤旗標的詳細資訊，請參閱 Microsoft 知識庫文章 920093 (機器翻譯) (http://support.microsoft.com/kb/920093)。

注意：如果資料庫使用資料行存放區索引，SQL Server 2012 目前不支援同時採用 –T834 的功能。如果您打算使用資料行存放區索引，請勿使用此追蹤旗標。

SQL 最大記憶體

若為 SQL Server 2012，可配置到 SQL Server 的伺服器 RAM 不得超出 RAM 總額的 92%。若有其他應用程式共用伺服器，則應據以調整可供作業系統使用的剩餘 RAM 數量。此設定是由 [最大伺服器記憶體] 選項所控制。如需驗證參考架構之記憶體設定的詳細資訊，請參閱 FTDW 夥伴文件。

資源管理員

資料倉儲工作負載通常包含操作大量資料的複雜查詢。這些查詢可能使用大量記憶體，並可能在記憶體受限的情況下溢出到磁碟。此行為對於資源管理特別有影響。使用 SQL Server 2012 的資源管理員技術，您就可以妥善管理資源使用狀況。

在 SQL Server 的預設設定中，資源管理員最多只會將 25% 的 SQL Server 記憶體提供給每個工作階段。這表示在最糟的情況下，三個足以使用至少 25% 可用記憶體的大量查詢將會導致其他任何需要大量記憶體的查詢無法執行。在此情況下，需要授與大量記憶體才能執行的其他任何查詢將排入佇列，直到獲得可用資源才會執行。

您可以使用資源管理員降低每個查詢使用的最大記憶體。不過，這樣會導致使用大量記憶體的並行查詢改用 tempdb，進而造成隨機紊亂的 I/O 模式，最後降低了整體輸送量。雖然許多資料倉儲工作負載可利用此方式來限制個別工作階段可用的系統資源數量，但是建議您最好透過分析並行查詢工作負載加以評估。如需資源管理員使用方式的詳細資訊，請參閱＜使用資源管理員管理 SQL Server 工作負載＞(http://msdn.microsoft.com/zh-tw/library/bb933866.aspx)。

您也應檢閱快速追蹤方案的廠商特定指引和作法。值得特別注意的是，對於較大型的 4 個通訊端和 8 個通訊端快速追蹤方案，您可能需要特殊的資源管理員設定才能達到最佳效能。

總而言之，降低限制雖然可以為各個查詢提供更高的效能，但嚴格的限制卻能保證可同時執行的查詢數目。

如需資源管理員之最佳作法和常見案例的詳細資訊，請參閱技術白皮書：《使用資源管理員》 (http://msdn.microsoft.com/zh-tw/library/ee151608.aspx)。

儲存體系統

若為將主要資料庫儲存體置於硬碟機 (HDD) 上的 FTDW 參考架構，如何妥善管理片段對於系統的長期效能而言是非常重要的一環。因此，我們特別指定規範了詳細的儲存和檔案系統組態。

儲存體系統元件

圖 3 提供的檢視顯示了針對整合式資料庫堆疊所合併的三個主要儲存體組態層。此圖應視為參考案例，因為具體拓撲會隨快速追蹤夥伴而大不相同。典型的資料庫堆疊包含下列元素：

· 「實體磁碟陣列：4 個讀寫頭 RAID 1+0」是圖 3 所示的標準方法。某些 SQL Server 2008 R2 和 SQL Server 2012 的夥伴參考架構也使用 RAID 5 和 RAID 6。

· 作業系統磁碟區指派 (LUN)

· 資料庫：使用者、系統暫存、系統記錄

圖 3：以三個儲存裝置為基礎之 FTDW 系統的完整儲存架構範例 (其中每個磁碟群組各有一個 LUN (磁碟區))

儲存體組態詳細資料

請針對每個儲存裝置執行下列作業：

1. 使用 RAID 1+0 (RAID 10) 建立包含四個磁碟的磁碟群組。每個儲存裝置的磁碟群組實際數目會依廠商而異。如需詳細資訊，請參閱廠商特定的文件。一般而言，數目為 (2) RAID10 和 (1) RAID1 的磁碟群組適用於大型 (LFF) 裝置，而數目為 (5) RAID10 的磁碟群組適用於小型 (SFF) 裝置。

作為主要資料之檔案群組位置的磁碟區總數不應超出 32。如果儲存體系統 LUN 的總數超出此臨界值，可使用較大的磁碟群組以減少 LUN 計數，同時維持類似的 I/O 輸送量。例如，您可以使用具有 1 個 LUN 的 8 磁碟 RAID 10 磁碟群組，而不是具有 1 個 LUN 的 4 磁碟 RAID 10 磁碟群組。較大的磁碟群組的輸送量和效率會稍微降低。這點會依儲存技術不同而有所差異。

2. 為主要使用者資料 (PRI) 指定一個專用磁碟群組。主要使用者資料位置與 SQL Server 資料庫檔案群組位置相同。所有 FTRA 都要求每個 PRI 磁碟群組具有一或兩個 LUN。請參閱您所選參考架構之廠商特定的指引。這些 LUN 可用來儲存 SQL Server 資料庫檔案 (.mdf 和 .ndf 檔)。

3. 針對儲存裝置內主要資料的每個磁碟區配置主要儲存體處理器之後，確定指派數量均勻平衡。例如，配置四個磁碟區給主要資料的儲存裝置，會將其中兩個磁碟區指派給儲存體處理器 “A”，並將另外兩個磁碟區指派給儲存體處理器 “B”。

4. 在其餘磁碟群組上建立一個 LUN，以裝載資料庫交易記錄。對於某些較大的快速追蹤組態，記錄配置僅限於系統中的前幾個儲存裝置。在此情況下，系統會針對非暫存資料庫使用額外磁碟群組，或保持未擴展狀態以降低成本。

請針對每個資料庫執行下列作業：

1. 至少建立一個檔案群組，其中每個 PRI LUN 各包含一個資料檔案。請務必使所有檔案大小都相同。如果您打算在一個資料庫中使用多個檔案群組來分隔物件 (例如一個支援載入的暫存資料庫)，請務必包含所有 PRI LUN 以作為每個檔案群組的位置。

2. 當您建立每個檔案群組的檔案時，請為這些檔案預先配置最大的預期大小，其大小應足以容納預期的物件。

3. 停用資料檔案的自動成長選項，並在接近目前大小限制時，手動擴充所有資料檔案。

4. 如需使用者資料庫和檔案群組之建議的詳細資訊，請參閱本文的＜管理資料片段＞一節。

請針對 tempdb 執行下列作業：

1. 預先配置空間，然後為每個 LUN 新增一個資料檔案。請務必使所有檔案大小都相同。

2. 將暫存記錄檔指派給記錄檔專用的其中一個 LUN。

3. 啟用自動成長；一般而言，資料倉儲工作負載適合使用大量成長增量。相當於初始檔案大小 10% 的值是一個合理的起點。

4. 遵循資料庫的標準 SQL Server 最佳作法及 tempdb 調整大小考量。在倉儲的移轉階段期間或初始資料載入期間，可能需要配置較大的空間。如需詳細資訊，請參閱《SQL Server 線上叢書》中的＜tempdb 的容量計畫＞(http://msdn.microsoft.com/zh-tw/library/ms345368.aspx)。

請針對交易記錄執行下列作業：

1. 針對每個資料庫，在指派給交易記錄空間的其中一個 LUN 上建立一個交易記錄檔。將不同資料庫的記錄檔分配給不同的可用 LUN，或視需要針對記錄檔成長使用多個記錄檔。

2. 啟用記錄檔的自動成長選項。

3. 確定記錄檔容量符合表 5 中提供的需求。視特定系統設計特性而定，您可進行些微改變。

系統 RAM (GB)

FT 額定容量 (TB)

建議的最小記錄配置

鏡像的可用空間 (GB)

<= 96

<=10

300 GB X 1 個磁碟區

<= 128

>10

<=40

300 GB x 2 個磁碟區

或

600 GB x 1 個磁碟區

表 5：記錄配置建議

請參閱 SQL Server 交易記錄配置和管理的現有最佳作法。

固態儲存體

針對主要 (PRI) 資料使用固態儲存體的 FTDW 參考架構具有許多優點，其中包括管理手續簡化、作業成本較低及維護期間可事先預測。

管理手續簡化：固態儲存體不需要片段管理。您仍應使用 SQL Server 啟動選項 –E，但不需要進一步最佳化或管理分頁配置。需要長期管理 FTDW 環境時，這項簡化措施可管理工作變得更容易。此外，您可以使用較大的磁碟群組及數目較低的磁碟區/LUN，而不會對效能造成負面影響。這項變更可簡化檔案群組的建立和維護作業。

I/O 彈性：在高度並行運作或頁面非常分散的情況下，固態儲存體的效能僅會些微降低。此外，混合的隨機讀取 (搜尋) 工作負載不會對大型要求 (掃描) I/O 模式造成負面影響。

可預測的維護：許多固態儲存體選項都提供軟體寫入有效期監控，因此降低了難以預測實體故障的情況發生。

較低的作業成本：固態儲存體的定價雖然較貴，但對於 I/O 輸送量與每單位容量之間的平衡效益卻更高。300 GB 10k SAS HDD 的有效 FTDW 工作負載 I/O 速率平均為 50 MB。企業級 MLC SSD 在 600 GB 容量下可提供 150 到 200 MB。此外，固態儲存體使用的電力相當少、產生較少熱度，且通常支援較高密度的方案。

固態儲存體組態

如果針對 PRI 磁碟區使用固態儲存體，可對標準 FTDW 儲存體組態方針進行下列調整。

· 如果需要鏡像，可使用 RAID1+0 或 RAID5。在不影響效能的情況下，RAID5 可為固態儲存體上的 FTDW 工作負載提供最佳容量。

· 您可以將 LUN 和磁碟區計數減少到每個儲存裝置只有一個 PRI 磁碟區。在某些情況下，使用 CPU 核心計數倍數的 PRI 磁碟區計數會很有幫助。PRI 磁碟區計數下限為 2。

· 交易記錄也可置於固態儲存體，但 FTDW 工作負載通常不一定需要記錄。將記錄檔置於傳統 HDD 可降低成本。這對 Windows Server 和 SQL Server 安裝的本機儲存體而言也是如此。

· 您可以略過頁面片段管理和叢集索引平行載入的建議，因為邏輯資料庫片段不會影響固態儲存體的 I/O 效能。

FTDW 的 SQL Server 最佳作法

快速追蹤工作負載的作法已經過驗證，並分成兩種情況記錄。第一種情況發生在快速追蹤作法與既有 SQL Server 最佳作法明顯不同時。第二種情況發生在現有作法遺失或無法輕鬆存取時。由於有關 SQL Server 資料庫部署的現有文件集很豐富，因此此處僅提供部分作法。對於 FTDW 部署相關的許多主題，請參閱現有的 SQL Server 技術文件和最佳作法。

重要事項：本指南提供數個針對 SQL Server 2008 R2 撰寫的文件連結。我們相信大部分的指引對於 SQL Server 2012 而言仍然有用。當這些文件提供更新版本時，建議您主動查閱。日後發行的參考指南將會納入更新過的連結。

資料架構資料表結構

在資料庫中用來儲存資料的資料表類型會影響循序存取的效能。因此在設計實體結構描述時，請務必注意這點，以讓查詢計畫盡可能產生許多循序 I/O。

選擇資料表類型取決於資料表中的資料在大部分時間的存取方式。根據儲存資料的詳細資料，您可以使用下列資訊協助判斷應考量的資料表類型。

堆積資料表

堆積資料表為資料表掃描提供乾淨、循序的 I/O，通常可降低與資料表片段相關的負擔。這些資料表本質上不允許最佳化 (直接存取) 透過叢集索引資料表找到的範圍掃描。在範圍掃描的情況下，堆積資料表會掃描整個資料表 (或者如果套用資料分割，則會掃描適當範圍的資料分割)。

掃描堆積資料表時，會在 32 個檔案時達到最大輸送量，因此對系統上具有高 LUN (大於 32) 或核心 (大於 16) 計數的大型事實資料表使用堆積時，可能需要使用資源管理員、DOP 條件約束，或變更標準快速追蹤資料庫檔案配置。

在下列情況中，最好使用堆積資料表：

· 大部分針對資料表參考的高優先順序查詢包含參考各種離散資料行的述詞，或不具有任何資料行述詞。

· 查詢通常執行大型掃描 (而不是限制範圍的掃描)，例如專門用來擴展 Analysis Services Cube 的資料表(在這類情況下，應使用與擴展 Analysis Services Cube 相同的資料粒度，對堆積資料表進行資料分割)。

· 為了在不增加索引管理負擔的情況下符合查詢工作負載需求，或載入效能最重要時 (堆積資料表的載入速度較快)。

叢集索引資料表

在資料倉儲環境中，當索引鍵為經常用於限制相關查詢工作負載之限定範圍的資料行 (例如日期) 時，叢集索引最有效。在此情況下，索引可用來大幅限制及最佳化要掃描的資料。

在下列情況中，最好使用叢集索引資料表：

· 在針對資料表的大多數高優先順序查詢工作負載案例中，可使用資料表中限定範圍的資料行來限制查詢。若為 FTDW 組態，叢集索引的日期資料分割資料行也應該是叢集索引鍵。注意：在某些情況下，選擇不是叢集索引資料表之日期資料分割資料行的叢集索引鍵可能會很有利。不過，除非載入「整個」資料分割，否則可能會產生片段，因為與現有叢集索引鍵重疊的新資料會建立頁面分割。

· 針對資料表的查詢通常會執行細微或限制範圍的查閱，而不是完整資料表或大型多重範圍的掃描。

資料表資料分割

資料表資料分割是管理 FTDW 資料庫中片段的重要工具。例如，您可以使用資料分割更新或刪除資料表中之範圍架構使用者資料的大型區塊，而不需要處理資料表的其他部分。相反地，從叢集索引逐列刪除會產生極大的範圍片段。常見的情況包括為舊資料分割重建較新的資料分割，且此資料範圍的 DML 作業頻率降低時。此資料分割現在相對於 DML 作業較穩定，且具有最小的範圍片段。

此外，您可以將主要用於擴展 SQL Server Analysis Services Cube 的大型資料表，建立為資料分割堆積資料表，其中資料表資料分割與 Cube 資料分割一致。存取時，只會掃描大型資料表的相關資料分割 (支援 Analysis Services ROLAP 模式之資料分割的結構可能比叢集索引的結構更佳)。

如需資料表資料分割的詳細資訊，請參閱技術白皮書：《使用 SQL Server 2008 的分割資料表和索引策略》(http://msdn.microsoft.com/zh-tw/library/dd578580(v=SQL.100).aspx)。

索引

請考量建立 FTDW 索引的下列方針：

· 針對日期範圍或常見限制使用叢集索引。

· 盡可能使用資料行存放區索引。下一節討論在 FTDW 環境中使用資料行存放區索引的最佳作法。

· 如果需要細微查閱，但資料表資料分割的效能不夠，請保留非叢集索引。如果可能，請使用資料行存放區索引作為非叢集索引的替代方案。

· 非叢集涵蓋索引可能會提供值給一些資料倉儲工作負載。您應該根據特定情況評估，並與資料行存放區索引進行比較。

xVelocity 記憶體中資料行存放區索引

SQL Server 2012 引進以分欄技術為基礎的新資料倉儲查詢加速功能：資料行存放區索引。這些新的索引結合增強的查詢處理功能，可提升各種分析查詢的資料倉儲查詢效能。

xVelocity 記憶體最佳化的資料行存放區索引是「單純」(非混合) 的資料行存放區，因為這些資料行存放區會在個別頁面上儲存所包含之資料行的所有資料。資料行存放區索引可提升 I/O 掃描效能及緩衝區叫用率，並適當配合 FTDW 設計方法。

最佳作法

資料行存放區索引物件位於資料表所在位置，並以類似非索引叢集的方式建立。這些情況表示需要遞增儲存容量。除非索引的目標資料表預期會經常變更，否則不需要在個別檔案群組中建立資料行存放區索引。在個別檔案群組中維護資料行存放區索引，可協助您在高度易變的環境中長時間管理頁面片段。

建立正規化資料模型的資料行存放區索引

一般資料模型 (亦即 3NF) 通常會觸發兩個或多個大型 (事實) 資料表之間的聯結。這些聯結類型目前並不適合處理資料行存放區索引，並且可能會顯示與非資料行存放區索引查詢計畫相關的效能降低。下列方法可協助您避免一般資料模型發生此問題：

· 使用查詢層級提示來封鎖資料行存放區索引處理的使用。

· 使用 OPTION(IGNORE_NONCLUSTERED_COLUMNSTORE_INDEX)

· 重寫查詢。如需詳細資訊，請參閱本文的＜資料行存放區索引一般最佳作法＞一節所列出的資源。

· 請嘗試省略 SQL 聯結所涉及之一個資料表中的一般聯結索引鍵，此 SQL 聯結顯示來自非資料行存放區索引查詢計畫的效能降低。省略某個資料表之資料行存放區索引中的聯結索引鍵，會導致在省略之資料行聯結的查詢不會使用資料行存放區索引。在無法套用查詢層級選項的環境中，這個方法可能會很有用。請注意，省略資料行存放區索引中的資料行不保證會有較佳的查詢計畫結果，且可能會影響資料行存放區索引對效能有幫助的其他查詢。如果您選擇使用此選項，從一小部分資料表選取資料行可降低對其他查詢的效能影響。請注意，宣告 (DDL) 的主索引鍵必須包含在資料行存放區索引中，因此可能會限制可用的聯結資料行。即使您省略資料行存放區索引定義中的主索引鍵資料行，所有主索引鍵資料行還是會在建立資料行存放區索引時，自動加入資料行存放區索引。

雖然一般資料模型未針對目前版本的資料行存放區索引進行完美的最佳化，但是請注意，FTDW 基準是以 TPC-H 之修改過的版本為基礎，此版本是正規化的模型。混合資料行存放區索引和非資料行存放區索引查詢計畫的並行工作負載經評估仍具有許多優點，包括 FTDW 額定輸送量在某些情況下，幾乎是整體工作負載效能的兩倍。

建立維度資料模型的資料行存放區索引

若為維度模型 (例如星狀結構描述)，請遵循標準資料行存放區索引最佳作法。這可視為資料行存放區索引處理的最佳個案案例。

資料行存放區索引的記憶體管理

針對 SQL Server 2012 驗證之 FTRA 所具有的系統 RAM 總計，通常比 SQL Server 2008 R2 的類似組態多。主要原因是增強資料行存放區索引的工作負載可透過較大的記憶體集區更有效率地執行。您應該一律使用資源管理員，為您打算利用資料行存放區索引的 FTDW 環境，設定每個工作階段的最大記憶體數量。經過驗證的 FTRA 會記錄用於達成 FT 額定效能的資源管理員設定，並會將這些值視為客戶工作負載的起點。在理想情況下，會在安裝系統之後，評估此設定並針對客戶工作負載進行調整。

下列 SQL 命令可根據這些建議設定 SQL Server 資源管理員。在此案例中，每個工作階段的最大記憶體數量會設為 19%。

ALTER RESOURCE GOVERNOR RECONFIGURE;

ALTER WORKLOAD GROUP [default] WITH(request_max_memory_grant_percent=19);

xVelocity 記憶體最佳化的資料行存放區索引最佳作法

FTDW 參考指引只會包含快速追蹤特有的作法。如需資料行存放區索引的詳細資訊，請參閱＜SQL Server 2012 CSI 微調指南＞(http://social.technet.microsoft.com/wiki/contents/articles/sql-server-columnstore-performance-tuning.aspx) 及＜SQL Server 2012 CSI 常見問題集＞(http://social.technet.microsoft.com/wiki/contents/articles/sql-server-columnstore-index-faq.aspx)。

資料庫統計資料

有關執行統計之時機及更新統計資料之頻率的決策，不會只根據一項因素。解決資料庫統計資料問題的兩個主要原因，通常取決於可用的維護時段以及整體系統效能是否充足。

如需詳細資訊，請參閱＜SQL Server 2008 的統計資料＞(http://msdn.microsoft.com/zh-tw/library/dd535534.aspx)。

最佳作法

我們建議您針對資料庫統計資料使用下列最佳作法：

· 使用 AUTO CREATE 和 AUTO UPDATE (同步或非同步) 選項進行統計 (SQL Server 的系統預設值)。透過此技術可將手動執行統計的需求降到最低。

· 如果您必須手動收集統計資料，在理想情況下，應收集資料表之所有資料行的統計資料。如果無法針對所有資料行執行統計，您應該至少收集在 WHERE 或 HAVING 子句中，以及在聯結索引鍵上使用之所有資料行的統計資料。索引建立會在索引鍵上建立統計資料，因此您不需要明確執行此作業。

· 複合 (多資料行) 統計資料對於許多聯結案例而言很重要。需要複合聯結索引鍵的事實-維度聯結，可能會在缺少複合統計資料的情況下，產生次佳的巢狀迴圈最佳化計畫。自動統計資料不會建立、重新整理或取代複合統計資料。

· 您應該在每次累加式載入作業之後，手動更新需要遞增索引鍵值 (例如事實資料表中的日期) 的統計資料。在其他所有情況下，您不需要經常更新統計資料。如果您認為 AUTO_UPDATE_STATISTICS 選項不足已滿足您的需求，請定期執行統計作業。

壓縮

所有 FTDW 組態的設計都啟用了頁面壓縮功能。建議您對所有事實資料表使用頁面壓縮。對於小型維度資料表 (亦即少於一百萬個資料列的資料表)，您可自行選擇是否要進行壓縮。頁面壓縮通常對較大型的維度資料表較有幫助。不論是哪一種情況，您都應該根據使用案例來評估維度資料表的壓縮。對於特定資料類型來說，資料列壓縮則是另一個提供合理之壓縮比的選項。

SQL Server 頁面壓縮會壓縮資料表、索引及資料分割中的資料。如此可降低儲存使用者資料表所需的實體空間大小，進而將更多資料納入 SQL Server 緩衝集區 (記憶體) 中。這麼做的一個優點是可減少實體儲存體服務的 I/O 要求數目。

可實現的實際壓縮數量會依儲存的資料及該資料內重複資料欄位的頻率而有所不同。如果您的資料呈現高度隨機紊亂的狀態，則壓縮的優點會很有限。即使在最佳的情況下，使用壓縮還是會增加 CPU 壓縮及解壓縮資料的需求，但是同時也會降低實體磁碟空間需求。而且在大多數情況下，藉由從記憶體緩衝區服務 I/O 要求，查詢回應時間也獲得改善。頁面壓縮的壓縮比 (原始大小/壓縮大小) 通常介於 2:1 到 7:1 之間，一般保守估計為 3:1。您的結果會依資料特性而有所不同。

管理資料片段

片段可能會發生在數個層級，不論是哪個層級，都必須加以控制以確保循序 I/O。FTDW 的一個主要目標是盡可能保持資料的順序，同時限制潛在片段。如果允許發生片段切割，整體系統效能將會降低。

您必須定期重組，而下列指引有助於將耗時的重組程序次數降到最低。

檔案系統片段

每個資料庫檔案的磁碟區應該在 NTFS 檔案系統的實體磁碟上保持連續。建立時，將預期的大小上限預先配置給檔案，可避免在此層級發生片段。

請避免使用 NTFS 檔案系統重組工具。這些工具的設計是為了在作業系統層級使用，因此並不了解內部 SQL Server 資料檔案結構。

範圍片段

在 SQL Server 內，某個檔案中的所有頁面 (不論資料表關聯為何) 可能會變得交錯，而降低為範圍大小 (2M) 或頁面層級 (8K)。發生此情況的原因，通常是由於並行 DML 作業、過度資料列層級更新或過度資料列層級刪除。

當一或多個資料表發生問題時，完整重寫是確保檔案中具有最佳頁面配置的唯一方式。目前沒有解決此資料庫片段類型的替代方法。因此，請務必遵循載入資料及管理 DML 之 SQL Server 組態和最佳作法的方針。

下列查詢提供評估 FTDW 資料表之邏輯片段的重要資訊。平均片段大小是具有最高優先順序的度量。此值提供一個整數，代表以連續範圍叢集的平均 SQL Server 頁面數目。

SELECT  db_name(ps.database_id) as database_name

              ,object_name(ps.object_id) as table_name

              ,ps.index_id

              ,i.name

              ,cast (ps.avg_fragmentation_in_percent as int) as [Logical Fragmentation]

              ,cast (ps.avg_page_space_used_in_percent as int) as [Avg Page Space Used]

              ,cast (ps.avg_fragment_size_in_pages as int) as [Avg Fragment Size In Pages]

              ,ps.fragment_count as [Fragment Count]

              ,ps.page_count

              ,(ps.page_count * 8)/1024/1024 as [Size in GB]

FROM sys.dm_db_index_physical_stats (DB_ID() --NULL = All Databases

                                                              , OBJECT_ID('$(TABLENAME)')

                                                              , 1

                                                              , NULL

                                                              , 'SAMPLED') AS ps     --DETAILED, SAMPLED, NULL = LIMITED

INNER JOIN sys.indexes AS i

              on (ps.object_id = i.object_id AND ps.index_id = i.index_id)

WHERE ps.database_id = db_id()

    and ps.index_level = 0;

下表提供說明平均片段大小值的一般方針。

平均片段大小

狀態

動作

>400

理想

這是理想值，但對於某些資料結構而言，可能很難維護。

300-399

綠色

資料表會提供良好的 I/O 效能，且不需要維護邏輯片段。

150-299

黃色

邏輯片段最有可能影響的 I/O 效率。建議進行維護以改善片段計數。

10-149

紅色

嚴重的邏輯片段。對此結構提出大型 I/O 要求會產生大量的磁碟讀寫頭移動，並降低整體系統的 I/O 效率。

<10

紅色

如此低的平均片段大小值通常表示尚未設定 SQL Server 啟動選項 –E，或在啟動時無法辨識此選項。

表 6：平均片段大小值

最後請務必注意，您不應該評估小於 500 MB 之資料表或資料分割的平均片段大小結果。小型資料結構沒有足夠的總頁數，可達到高效率的片段計數。此外，這些較小的資料結構通常代表相對較小的資料要求，因此對整體系統 I/O 效率的影響有限。只在資料倉儲環境中管理最大且最常存取的資料表，通常會有最佳的結果。

索引片段

索引的實體 (頁面) 順序和邏輯 (索引) 順序可能不同。

請勿使用 ALTER INDEX REORGANIZE 命令來解決此片段類型，因為這麼做會讓大型配置的優點盡失。索引重建或使用 INSERT…SELECT 將資料插入索引的新複本 (避免重新排序)，可解決此問題。任何 ALTER INDEX REBUILD 程序都應該指定 SORT_IN_TEMPDB=TRUE，以避免產生目的地檔案群組片段。MAXDOP 值 1 為理想值，但可能導致載入速率很慢。在某些情況下，您最高可將 MAXDOP 值設為 8。如需詳細資訊，請參閱本文的＜載入資料＞一節。

多個檔案群組

您可以建立個別檔案群組，以將下列動態資料使用案例的邏輯片段降到最低：

· 經常捨棄及重新建立的資料表或索引 (在儲存體配置中留下需要重新填入其他物件的間隙)。

· 必須支援之因頁面分割而高度片段的索引，例如經常載入與現有叢集索引鍵範圍大部分重疊之累加資料的情況。

· 以相對較小之增量載入的較小資料表 (例如維度資料表)，您可以將此資料表置於動態檔案群組，以避免這些資料列與大型交易或事實資料表交錯。

· 其資料將插入最終目的地資料表的臨時資料庫。

您可以將其他資料表置於靜態的檔案群組中。此外，您也可以將極大型事實資料表置於個別檔案群組中。

載入資料

為了讓循序磁碟存取有較高的平均掃描速率，會平衡快速追蹤元件架構。若要維持這些掃描速率，您必須小心確認 SQL Server 檔案系統內的資料配置連續。

本節分成下列兩個高階方法：累加式載入及資料移轉。此為快速追蹤資料倉儲特有的指引，但不只限於此指引。

如需 SQL Server 大量載入的詳細資訊，請參閱＜資料載入效能指南＞(http://msdn.microsoft.com/zh-tw/library/dd425070.aspx)。

另一實用的資源則為「快速追蹤 3.0 資料載入最佳作法」指南。您可以在 SQL Server 快速追蹤資料倉儲入口網站 (http://msdn.microsoft.com/zh-tw/library/dd425070.aspx) 找到此 Microsoft PowerPoint 簡報。此文件最初雖然是根據 SQL Server 2008 R2，但仍適用於 SQL Server 2012。

累加式載入

本節討論資料倉儲環境的日常載入情況。本節包含具有下列一或多個特性的載入情況：

· 其大小相對於可用系統記憶體較小

· 可用記憶體可容納載入排序作業

· 其大小相對於目標載入物件中的資料列總數較小

當您載入堆積和叢集索引資料表時，應考量下列方針。

堆積資料表載入程序

您可以連續或並行的程序來實作堆積資料表的大量插入。請使用下列秘訣：

· 若要將資料移至目的地堆積資料表，請搭配 TABLOCK 選項使用 BULK INSERT。如果分割最終永久資料表，請使用 BATCHSIZE 選項，因為載入資料分割資料表會導致 tempdb 發生排序。

· 當您匯入大型資料集時，若要提升載入時間效能，請同時執行多個大量插入作業，以利用大量處理中的平行處理原則。

叢集索引載入程序

載入具有很少量之資料表片段的叢集索引資料表通常有兩個方式。

選項 1

使用 BULK INSERT 將資料直接載入目的地資料表。為取得最佳效能，載入的整組資料必須能夠納入記憶體中的排序作業。您應該使用 BATCHSIZE 值 0，透過單一認可作業來處理載入的所有資料。此設定可防止多個批次中的資料交錯及產生頁面分割。如果使用此選項，必須以單一執行緒的方式載入。

選項 2

建立符合目的地資料表結構 (包括資料分割) 的暫存資料表：

· 使用適中、非零的批次大小值，對空白叢集索引暫存資料表執行連續或多執行緒的大量插入，如此可避免排序溢出到 tempdb。透過特定程度的平行處理原則可達成最佳效能。此步驟的目標是效能，因此不需要擔心平行及/或並行插入所產生的頁面分割和邏輯片段。

· 搭配 MAXDOP 值 1 使用單一 INSERT…SELECT 陳述式，從暫存資料表插入目的地叢集索引資料表。MAXDOP 1 可確保最小範圍片段，但通常會犧牲效能。您最多可以使用 MAXDOP 為 8 的設定來提升載入效能，但隨著平行處理原則的增加，範圍片段也會增加。您最好根據特定的情況評估此取捨下的有效平衡。

選項 3

此選項需要使用兩個檔案群組和兩個 (含)以上的資料表。此方法需要一個資料分割叢集索引資料表，並且最適合最近的資料分割顯示高度邏輯片段、而舊資料分割沒有太多變更活動的資料表。其整體目標是要將動態資料分割置於專用檔案群組中，並在這些資料分割停止接收新記錄或現有記錄的變更之後，使其過時或移至靜態檔案群組

· 遵循 FTDW 指引建立兩個檔案群組。其中一個檔案群組將專用於動態資料分割，而另一個檔案群組將專用於靜態資料分割。動態資料分割 是指 10% 以上的資料列會隨時間而改變的資料分割。靜態資料分割 是指非易變的資料分割。

· 在靜態檔案群組中建立主要叢集索引資料分割資料表。

· 根據下列兩種一般方式之一建立資料表：

· 具有鏡像主要資料表的資料分割配置之條件約束的單一堆積資料表。此條件約束應代表主要資料集的動態範圍，並且可能會橫跨主要資料表配置的一或多個資料分割範圍。如果初始載入效能是關鍵決策準則，此方式最有用，因為載入到堆積資料表通常比載入到叢集索引更有效率。

· 具有與主要資料表資料分割一致之資料分割配置的單一叢集索引資料表。如此可在動態資料分割過時之際，以很低的平行處理原則程度 (DOP) 直接插入主要資料表。透過將資料分割插入主要資料表使其淘汰之後，即會捨棄資料分割並新增範圍。

· 建立將兩個資料表聯集在一起的檢視。此檢視會從使用者觀點，以單一物件來呈現這兩個資料表的組合。

· 當動態資料範圍從變更資料的觀點來看變成靜態之後，請使用適當的淘汰程序，例如資料分割切換：

· 如果使用具有條件約束的堆積資料表，請透過插入暫存資料表，將資料依資料分割範圍移至靜態檔案群組。使用 CREATE INDEX 和資料分割切換將資料移至主要資料表中。如需 FTDW 組態之此作業類型的詳細資訊，請參閱本文的＜資料移轉＞一節。

· 如果使用資料分割叢集索引，請使用小於或等於 8 的 DOP。接著，將受限的資料分割範圍直接插入主要資料表。您可能需要根據整體系統並行程度，將 DOP 最低設為 1 以避免片段。

資料移轉

此包括資料倉儲環境中的大型一次性或不頻繁的載入情況。在平台移轉期間，或基於系統效能評定而載入資料時，可能會發生這些情況。本主題包含具有下列一或多個特性的載入情況：

· 超過可用系統記憶體的載入作業

· 對可用記憶體造成壓力之高度並行、大量的載入作業

堆積資料表載入程序

請遵循稍早提供的累加式載入處理指引。

叢集索引載入程序

載入具有很少量之資料表片段的叢集索引資料表通常有數個方式。

選項 1

使用 BULK INSERT 將資料直接載入目標叢集索引資料表。排序作業和完整認可大小應該能夠納入記憶體，以取得最佳效能。您必須小心確保分批載入的資料沒有重疊的索引鍵範圍。

選項 2

對相同結構的空白叢集索引暫存資料表，執行連續或多執行緒的大量插入。使用適中、非零的批次大小將排序保留在記憶體中。接著，搭配 MAXDOP 值 1 使用單一 INSERT…SELECT 陳述式將資料插入空白叢集索引資料表。

選項 3

對堆積暫存資料表資料分割使用多執行緒的大量插入，並使用適中、非零的批次大小值將排序保留在記憶體中。接著，在每個資料分割範圍連續或平行使用 INSERT…SELECT 陳述式，將資料插入叢集索引資料表。

選項 4

在多步驟的程序中使用資料分割切換作業，通常會為大型載入作業提供最佳結果。此方法會增加整體程序的複雜度，其設計目的是為了示範對原始載入效能最佳的方法。此方法的主要目標在於啟用插入叢集索引作業之所有階段的平行寫入活動，而不引進邏輯片段。您可以在多個檔案群組接移資料表，再將資料插入最終目的地資料表，以達成此目標。

1. 識別最終目的地叢集索引資料表的資料分割配置。

2. 建立暫存檔案群組。

3. 在暫存檔案群組中，建立未壓縮且未分割的堆積「基底」暫存資料表。

4. 使用 WITH TABLOCK 將資料大量插入基底暫存資料表。如果選擇使用多個來源的檔案，則多個平行的大量複製作業會是最有效率的方法。達到最大輸送量的平行載入作業數目取決於伺服器資源 (CPU 和記憶體) 及載入的資料。

5. 識別要支援的主要檔案群組數目。此數目應該是目的地資料表中之資料分割總數的倍數。此數目也可代表要在稍後步驟中並行執行的 INSERT 和 CREATE INDEX 作業總數。例如，針對具有 24 個資料分割的資料表及 8 個核心的伺服器，會指出具有 8 個主要檔案群組的資料庫。此組態可在後續步驟中，針對這 8 個主要檔案群組和 CPU 核心執行 8 個平行插入 (每個主要檔案群組和 CPU 核心各 1 個)。在此情況下，每個檔案群組會包含三個資料分割範圍的資料。

6. 建立稍早確定之數目的主要檔案群組。

7. 在不壓縮的情況下，在每個主要檔案群組中，針對每個資料分割範圍建立暫存堆積資料表。建立暫存資料表的條件約束，以符合目的地資料表中的對應資料分割範圍。透過上述範例，在此步驟中為每個主要檔案群組建立三個暫存資料表。

8. 使用頁面壓縮，建立目的地資料分割叢集索引資料表。此資料表應在所有主要檔案群組進行分割。資料分割應該與堆積暫存資料表的條件約束範圍一致。

9. 針對每個主要檔案群組，執行從基底暫存資料表到的暫存檔案群組資料表的一個 INSERT 或 SELECT 陳述式。您應該平行完成此作業。確定 INSERT 或 SELECT 陳述式的述詞符合對應的資料分割範圍。針對每個檔案群組，請勿同時執行多個 INSERT 或 SELECT 陳述式。

10. 若為新擴展的暫存資料表，請針對每個檔案群組執行一個 CREATE CLUSTERED INDEX 命令 (搭配頁面壓縮)。您可以平行執行此作業，但 DOP 不得高於 8。請勿針對每個檔案群組，同時執行多個 CREATE INDEX。請務必在執行 CREATE INDEX 作業時使用 SORT_IN_TEMPDB 選項，以避免主要檔案群組發生片段切割。CREATE INDEX 作業的最佳並行數目會取決於伺服器大小、記憶體及資料本身。一般而言，請在所有核心努力取得高 CPU 使用量，但不要過量 (總使用量的 85-90%)。

11. 執行從暫存資料表到目的地資料表的連續資料分割切換作業。完成每個暫存 CREATE INDEX 作業也會完成此作業。

基準和驗證

本節提供設計及限定 SQL Server FTDW 參考架構所使用之程序的基本說明。提供這項資訊的目標在於支援以 FTDW 方法為基礎的使用者定義或自訂參考架構。如需對已發行及預先驗證的夥伴參考架構進行效能評定、疑難排解或驗證，請連絡發行夥伴 (H-P、Dell、EMC、IBM、Cisco 等)。

FTDW 驗證程序可分成此處所述的兩種類別。

基準硬體驗證

硬體驗證的目標是為了建立快速追蹤參考架構之主要硬體元件的實際 (而非額定) 效能標準。此程序決定資料庫堆疊中之主要硬體元件的實際基準效能特性。

快速追蹤資料庫驗證

根據 FTDW 工作負載建立的 SQL Server 效能特性，可與基準硬體評估程序所提供的效能假設進行比較。一般而言，資料庫工作負載輸送量標準，至少應反映經驗證之快速追蹤參考架構基準速率的 80%。在此程序中計算的效能標準是已發行之 FTDW 效能值的基礎，並以透過快速追蹤參考點效能評定工具所執行的並行 SQL 查詢工作負載為依據。

「參考點」是散發給快速追蹤硬體夥伴的 Microsoft 軟體工具，並且是 Microsoft 驗證及核准正式快速追蹤參考架構所使用的唯一基礎結構。此工具會具現化參考資料庫結構描述，並驅動專為識別瓶頸及建立主要系統效能基準所設計的多個並行查詢工作負載。

使用 xVelocity 記憶體最佳化的資料行存放區索引進行快速追蹤驗證

SQL Server 2012 實作資料行存放區索引技術，以作為已存在之資料表的非叢集索引選項。個別查詢是否使用資料行存放區索引最佳化計畫會視查詢結構而定。這表示在任何時間的 FTDW 環境中，您無法預測是否會混合傳統資料列與新的分欄查詢計畫。

因此，SQL Server 2012 R2 系統設計和驗證的 FTDW 會以非資料行存放區索引基準為基礎。FTDW 系統的設計，是為了在任何指定時間內未達成分欄最佳化的情況下有效執行。使用資料行存放區索引查詢計畫通常可大幅提升效能，且此效能可視為基本系統設計的累加。

SQL Server 2012 夥伴驗證的快速追蹤參考架構針對增強資料行存放區索引的基準，發行了額外的邏輯輸送量額定值，這些數值可用來模擬查詢效能客戶在並行查詢工作負載下可預期的正面影響。這些數值會以所有系統驗證使用的相同 FTDW 基準和結構描述為依據。

執行基準 FTDW 驗證

基準驗證會透過 SQLIO 等工具在作業系統層級完成。此階段不會執行 SQL Server 應用程式測試，且所有測試都是最佳綜合情況下的案例。其目標是為了確保硬體和作業系統組態正確，並根據設計和開發基準提供預期結果。

Windows Server 效能和可靠性監視器 (又稱為 perfmon) 可用來追蹤、記錄及報告 I/O 效能。SQLIO 等工具可用來測試 I/O 頻寬。如需 SQLIO 的詳細資訊，請參閱 SQLCAT 技術白皮書《前置部署 I/O 最佳作法》(http://sqlcat.com/sqlcat/b/whitepapers/archive/2007/11/21/predeployment-i-o-best-practices.aspx)。

您可以使用下列元件和驗證程序來產生硬體基準。

使用 SQLIO 測試基準

最佳作法文章將更完整說明如何使用 SQLIO。讀取測試通常採用下列格式：

sqlio –kR –fSequential -s30 -o120 -b512 d:\iobw.tst –t1

在此案例中，R 表示讀取測試，30 是測試持續時間 (以秒為單位)，120 是所發出未處理的要求數目，512 是提出要求的區塊大小 (以 KB 為單位)，d:\iobw.tst 是測試檔案的位置，而 1 是執行緒數目。

為了測試彙總頻寬案例，必須平行發出多個 SQLIO 測試。針對每個主要資料掛接點 (磁碟區) 應該使用一個 SQLIO 執行個體。您可以使用 Windows PowerShell 或其他指令碼處理方法，來達成 SQLIO 執行個體的平行處理。若為 FTDW 夥伴驗證的參考架構，您可以向夥伴取得基準 I/O 驗證指令碼。

＜前置部署最佳作法＞一文也涵蓋如何使用 Windows Server 效能和可靠性監視器來追蹤您的測試。記錄及儲存這些測試結果，將提供您未來效能分析和解決問題的一個基準。

步驟 1 - 驗證 I/O 頻寬

驗證 FTDW 組態的第一個步驟，是判斷儲存體 I/O 網路與伺服器之間可實現的最大彙總輸送量。此作業涉及移除成為瓶頸的磁碟，並著重於非磁碟的元件 (例如 HBA、交換器基礎結構及陣列控制器)。請使用下列步驟透過 SQLIO 執行此工作：

1. 在每個 LUN 上產生小型資料檔案，以作為資料庫檔案。您應該調整這些檔案的大小，使所有資料檔案都能納入陣列控制器的讀取快取中 (例如每個檔案 50 MB)。

2. 使用大型區塊 I/O 大小 (512K) 及每個檔案至少兩個讀取執行緒，透過 SQLIO 同時對檔案發出循序讀取。請務必計算未處理的彙總讀取數目。例如，各具有 50 個未處理要求的 2 個讀取執行緒，會向目標 LUN 提出共 100 個未處理的要求。

3. 請以未處理之 I/O (-o) 相對較低的值開始，然後重複測試並增加此值，直到彙總輸送量不再提高為止。

此測試的目標是為了達到與理論上伺服器和儲存體間路徑中的元件數目限制相較下，較合理的彙總輸送量。此測試會驗證伺服器與 SAN 儲存體處理器之間的頻寬 (亦即多重路徑光纖通道路徑)。

步驟 2 - 驗證 LUN/磁碟區頻寬

此測試類似上一個測試，但會使用較大的檔案以排除控制器快取之陣列快取的潛在優點。這些測試檔案的大小必須足以模擬每個磁碟區的目標資料庫檔案大小，例如每個磁碟區 25 GB。您應該如步驟 1 所述，針對 SQLIO 使用類似參數。

您應該對每個磁碟區的測試檔案發出大型區塊 (512 KB) 循序讀取。建議您針對每個檔案使用一個執行緒，其中未處理的要求深度介於 4 到 16 (由小開始，然後增加直到達到最大輸送量為止)。請先個別測試每個磁碟區，然後同時測試兩個磁碟區。磁碟群組輸送量會依儲存體廠商和組態而有所不同，但一律可與單一 HDD 讀取速率進行比較。例如，4 磁碟 RAID1+0 磁碟群組所能達到的尖峰讀取速率，幾乎是此基本讀取模式類型之單一 HDD 讀取速率的四倍。RAID 1 或 1+0 效能會依儲存體產品而有所不同，因為某些廠商技術允許「鏡像讀取」，因此在收到連續要求時，可從鏡像組的兩端提供 I/O。

步驟 3 - 驗證彙總頻寬

在此測試中，您應該針對步驟 2 所使用的相同檔案，在所有可用資料磁碟區同時執行循序讀取。您應該以每個測試檔案使用兩個執行緒的方式來執行 SQLIO，其中 I/O 大小為 512K，而未處理的 I/O 理想數目會由上一個測試來決定。

此測試的結果說明從實體磁碟讀取資料時可達到的最大彙總輸送量。

如同上一個測試，資料會從每個磁碟區的大型資料檔案同時讀取。

若為平衡的 FTDW 系統，來自磁碟的彙總效能應介於彙總儲存體 I/O 頻寬的 80% 至 90%。

元件額定值

下圖描述綜合基準結果，這些結果與類似之快速追蹤參考架構中所顯示的值一致。

圖 4：搭配 3 個 8Gbps 雙通訊埠 HBA 卡、12 4 磁碟 RAID1+0 主要資料磁碟區之 2 通訊端 12 核心伺服器的綜合基準實現頻寬範例

摘要

基準硬體效能評定會驗證資料庫堆疊之主要硬體元件的實際頻寬功能。透過 SQLIO 等工具在最佳綜合情況下執行一連串測試，即可完成此作業。

執行快速追蹤資料庫效能評定

FTRA 評估的這個階段會測量 FTDW 工作負載下的 SQL Server 效能，並以兩個核心度量為指標。第一個度量為最大 CPU 使用率 (MCR)，測量尖峰 I/O 處理輸送量。第二個度量為基準 CPU 使用率 (BCR)，測量查詢或查詢式工作負載的實際 I/O 處理輸送量。

何謂 MCR？

MCR 計算提供每一核心的 I/O 輸送量值 (以每秒 MB 或 GB 為單位)。若要測量此值，請從緩衝區快取執行預先定義、唯讀且未最佳化的查詢，然後測量資料量 (以 MB 或 GB 為單位) 的執行時間。因為 MCR 從快取執行，所以其代表透過評估系統之 SQL Server 所達成的尖峰未最佳化掃描速率。因此，MCR 可為初始設計目的提供基準尖峰速率。MCR 不是為了表示實際工作負載的平均或預期結果。經驗證的 FTDW 架構具有彙總基準 I/O 輸送量結果，此結果至少為伺服器額定 MCR 的 100%。換句話說，MCR 代表在合理、最糟情況的工作負載下，可能達成的最佳 SQL Server 處理速率。

MCR 也可在比較其他已發行及驗證的 SQL Server 2012 FTDW 參考架構時，作為參考框架。

總結：

· MCR 不是客戶工作負載的最後實際結果。

· MCR 為 SQL Server 及與快速追蹤工作負載相關的單一查詢，提供最大資料處理速率基準。

· MCR 取決於 CPU 和伺服器。一般而言，指定 CPU 的比率不會因伺服器和主機板架構而有很大的差異，但最終 MCR 應由實際測試來決定。

· MCR 輸送量額定值可作為與現有發行之 FTDW 參考架構的比較值。此值可協助選取硬體，再進行元件和應用程式測試。

計算 MCR

若要建立 SQL Server 應用程式的基準 CPU 使用率，請執行針對 FTDW 方案所定義的標準 SQL 查詢。此查詢的設計是為了以相對簡單的方式來表示工作負載類型 (在此案例中為資料倉儲) 的一般查詢，並從緩衝區快取執行。產生的值取決於執行的 CPU、伺服器及查詢。請使用下列方法來計算 MCR：

1. 根據 TPC-H 明細項目資料表建立參考資料集，或建立類似的資料集。針對此處提供的查詢，此資料表應該是可從 SQL Server 緩衝集區完整快取的大小，但仍維持至少 1 秒的執行時間。

2. 若為 FTDW，請使用下列查詢：SELECT sum([整數欄位]) FROM [資料表] WHERE [限制為適當的資料磁碟區] GROUP BY [資料行]。

3. 此環境應該：

· 確定將資源管理員設為預設值。

· 確定從緩衝區快取執行查詢。執行查詢一次會將頁面置於緩衝區中，後續執行應完全從緩衝區讀取。驗證查詢統計資料輸出中沒有實體讀取。

· 將 STATISTICS IO 和 STATISTICS TIME 設為 ON 以輸出結果。

4. 執行多次查詢，其中 MAXDOP = 4。

5. 記錄每個查詢執行之統計資料輸出中的邏輯讀取次數和 CPU 時間。

6. 使用下列公式計算 MCR (以 MB/s 為單位)：( [邏輯讀取次數] / [CPU 時間 (以秒為單位)] ) * 8KB / 1024

7. 至少於 5 次查詢執行值後，應出現範圍一致的值 (+/- 5%)。若出現差異過大的極端值 (+/- 20% 或以上)，則可能表示組態有問題。FTDW MCR 即為 5 次計算後的平均結果。

根據 MCR 計算，可建構元件架構輸送量圖表。為了計算系統 MCR，元件輸送量會以廠商額定的頻寬為依據。此圖表有助於系統設計、選取及瓶頸分析。圖 5 描述此範例。

圖 5：以 Intel Westmere CPU 為基礎之 2 通訊端 12 核心伺服器的最大 CPU 使用率 (MCR) 及額定元件頻寬範例

如需測量 MCR 的詳細資訊，請參閱附錄中的＜工作負載測試＞。

計算 BCR

若要建立 SQL Server 應用程式的基準 CPU 使用率，請在適當的並行層級下，執行一組針對您的資料倉儲工作負載的基準 SQL 查詢。所使用的查詢數目和並行層級完全取決於預期的使用案例。查詢工作負載應從磁碟提供，而不是和 MCR 一樣從 SQL Server 緩衝集區提供。產生的值取決於執行的 CPU、伺服器及工作負載。附錄項目＜工作負載測試＞提供建立 BCR 工作負載基準的更詳細範例。

請使用下列方法來計算 BCR：

1. 建立至少包含一個資料表的參考資料集。此資料表應該夠大，但不是可從 SQL Server 緩衝集區快取或 SAN 陣列快取完整快取的大小。若缺乏客戶資料，可以使用綜合資料集。請務必嘗試模擬目標使用案例的預期資料特性。

2. FTDW 的基本查詢格式如下：SELECT sum([整數欄位]) FROM [資料表] WHERE [限制為適當的資料磁碟區] GROUP BY [資料行]。如果沒有現成的客戶查詢，您可以此作為查詢工作負載設計的起點。TPC-H 是可當做參考查詢集的另一個常用查詢基準。

3. 針對 FTDW 客戶基準，選擇目標工作負載的代表性查詢一律是最理想的作法。您應該在多個並行工作階段排定這些查詢，這些工作階段代表客戶環境的過去或預期尖峰活動。選取查詢時，可考慮下列準則：

· 代表平均目標工作負載需求。這可能表示增加或減少基本查詢格式的複雜性、新增聯結，及/或透過預測和限制捨棄更多或更少資料。

· �