爲緩衝區數據（BufferTempStoragePath 屬性）和包含二進制大型對象 (BLOB) 數據的列（BLOBTempStoragePath 屬性）指定臨時存儲位置。默認情況下，這些屬性包含 TEMP 和 TMP 環境變量的值。您可能希望指定不同或更快的硬盤驅動器上的其他文件夾來存放臨時文件，或將它們分佈在多個驅動器上。可以指定多個目錄，並用分號來分隔這些目錄名。
通過設置 DefaultBufferSize 屬性定義任務使用緩衝區的默認大小，並通過設置 DefaultBufferMaxRows 屬性來定義每個緩衝區中最大的行數。默認緩衝區大小爲 10 MB，最大緩衝區大小爲 100 MB。默認最大行數爲 10,000。
通過設置 EngineThreads 屬性來設置任務在執行過程中可使用的線程數。此屬性爲數據流引擎提供有關使用線程數的建議。默認值爲 5，最小值爲 3。但是，不論此屬性值爲多少，引擎都不會使用超過其所需的線程數。如果需要避免併發問題，引擎所使用的線程數也可能會超過此屬性指定的線程數。
指示數據流任務是否以優化模式運行（RunInOptimizedMode 屬性）。優化模式會從數據流刪除未使用的列、輸出和組件，從而提高性能。
 注意 |
|---|
|
可以在 Business Intelligence Development Studio 中的項目級設置同名屬性 RunInOptimizedMode，以指示調試過程中數據流任務以優化模式運行。此項目屬性在設計時將覆蓋數據流任務的 RunInOptimizedMode 屬性。 |
調整緩衝區大小
數據流引擎通過計算一行數據的估計大小來開始調整其緩衝區大小的任務。然後引擎將估計的單行大小與 DefaultBufferMaxRows 值相乘以獲得緩衝區大小的初步工作值。
如果該結果大於 DefaultBufferSize 值，引擎將減少行數。
如果該結果小於內部計算的最小緩衝區大小，引擎將增加行數。
如果結果在最小緩衝區大小和 DefaultBufferSize 值之間，引擎將調整緩衝區大小，以儘可能接近估計行大小乘以 DefaultBufferMaxRows 值得出的結果。
當您開始測試數據流任務的性能時，請使用 DefaultBufferSize 和 DefaultBufferMaxRows 的默認值。對數據流任務啓用日誌記錄，並選擇 BufferSizeTuning 事件以查看每個緩衝區中包含多少行。
在開始調整緩衝區大小之前，您可以採取的重要改進措施是通過刪除不需要的列並配置相應的數據類型來減少每一個數據行的大小。
在有足夠的可用內存時，請使用少量的大緩衝區，而不是大量的小緩衝區。換而言之，可以通過減少存放數據所需的緩衝區總數並在一個緩衝區中放置儘可能多的數據行來改善性能。若要確定緩衝區的最佳數目及其大小，請在試驗 DefaultBufferSize 值和 DefaultBufferMaxRows 值的同時監視性能以及由 BufferSizeTuning 事件報告的信息。
不要將緩衝區大小增加到開始對磁盤進行分頁的點。與未經過優化的緩衝區大小相比，對磁盤進行分頁對性能的阻礙作用更大。若要確定是否在進行分頁，可監視 Microsoft 管理控制檯 (MMC) 的性能管理單元中的“Buffers spooled”性能計數器。
將包配置爲支持並行執行
並行執行能改善具有多個物理或邏輯處理器的計算機的性能。爲了支持在包中並行執行不同的任務，Integration Services 使用兩個屬性：MaxConcurrentExecutables 和 EngineThreads。
MaxConcurrentExcecutables 屬性
MaxConcurrentExecutables 屬性是包本身的一個屬性。此屬性定義可同時運行的任務的數量。默認值爲 -1，表示物理或邏輯處理器的個數加 2。
若要了解此屬性的工作原理，可參考一個包含三個數據流任務的示例包。如果將 MaxConcurrentExecutables 設置爲 3，則可以同時運行所有三個數據流任務。但是，假定每個數據流任務都具有 10 個源到目標執行樹。將 MaxConcurrentExecutables 設置爲 3 不能確保每個數據流任務內的執行樹都能並行運行。
EngineThreads 屬性
EngineThreads 屬性是每個數據流任務的屬性。此屬性定義數據流引擎可以創建和並行運行的線程數。EngineThreads 屬性同樣適用於數據流引擎爲源創建的源線程和該引擎爲轉換和目標創建的工作線程。因此，將 EngineThreads 設置爲 10 表示該引擎可以創建多達 10 個源線程和多達 10 個工作線程。
若要理解此屬性的工作原理，可參考包含三個數據流任務的示例包。每個數據流任務都包含 10 個源到目標執行樹。如果將每個數據流任務的 EngineThreads 設置爲 10，則可以同時運行所有 30 個執行樹。
| 注意 |
|---|
|
線程不在本主題的討論範圍之內。但是，通用規則是並行運行的線程數不要多於可用的處理器個數。運行的線程數多於可用的處理器個數可能會降低性能，因爲此時需要在線程間頻繁進行上下文切換。 |
配置單個數據流組件 若要配置單個數據流組件以優化性能，可以按照某些通用指導原則進行操作。同時還存在針對各種類型的數據流組件的特定指導原則：源數據流組件、轉換數據流組件和目標數據流組件等。
通用指導原則
無論採用何種數據流組件，爲了改善性能您應該遵循下面兩個通用指導原則：優化查詢和避免不必要的字符串。
優化查詢
大量數據流組件都將在從源中提取數據時，或在查詢操作中創建引用表時使用查詢。默認查詢使用 SELECT * FROM <表名> 語法。這種類型的查詢返回源表中的所有列。在設計時使所有列可用，這意味着可以選擇任意列作爲查找列、傳遞列或源列。但是，在選擇了要使用的列後，您應該修改查詢使其只包括那些所選擇的列。刪除多餘的列可以使包中的數據流更高效，因爲列越少則創建的行越小。因爲行越小，可以置入一個緩衝區的行就越多，對數據集中所有行進行處理的工作量也就越少。
您可以鍵入查詢或使用查詢生成器來構造查詢。
| 注意 |
|---|
|
在 Business Intelligence Development Studio 中運行包時，SSIS 設計器的“進度”選項卡將列出警告信息。其中包括當源向數據流提供了某個數據列但下游數據流組件卻沒有使用它時出現的警告信息。您可以使用 RunInOptimizedMode 屬性來自動刪除這些列。 |
避免不必要的排序
排序本身是非常緩慢的操作，因此避免不必要的排序可以提高包數據流的性能。
某些情況下，源數據在下游組件使用其之前已經進行了排序。當 SELECT 查詢使用 ORDER BY 子句或者數據按排序順序插入源中時，即出現這種預排序。對於這種預排序的源數據，您可以提供一個提示說明數據已排序，從而避免使用排序轉換來滿足特定下游轉換的排序要求。（例如，合併和合並聯接轉換要求使用已排序的輸入。）若要提供一個提示說明數據已排序，必須執行下面的任務：
將上游數據流組件輸出上的 IsSorted 屬性設置爲 True。
然後指定數據排序所依據的排序鍵列。
有關詳細信息，請參閱如何爲合併轉換和合並聯接轉換排序數據。
如果必須在數據流中對數據排序，則可以將數據流設計爲使用儘可能少的排序操作來提高性能。例如，數據流使用多播轉換複製數據集。可以在多播轉換運行前對數據集進行一次排序，而不是在轉換後再對多個輸出進行排序。
有關詳細信息，請參閱排序轉換、合併轉換、合併聯接轉換和多播轉換。
源
OLE DB 源
使用 OLE DB 源從視圖中檢索數據時，選擇“SQL 命令”作爲數據訪問模式並輸入 SELECT 語句。訪問數據時，使用 SELECT 語句要比選擇“表或視圖”作爲數據訪問模式的執行效果更佳。
轉換
使用本節中的建議可以改善聚合、模糊查找、模糊分組、查找、合併聯接和漸變維度轉換的性能。
聚合轉換
聚合轉換包括 Keys、KeysScale、CountDistinctKeys 和 CountDistinctScale 屬性。通過使用這些屬性，使轉換能夠爲轉換緩存的數據預先分配轉換所需的內存量，從而提高了性能。如果知道要從“分組依據”操作產生的準確或近似組數，則可分別設置 Keys 和 KeysScale 屬性。如果知道要從“非重複計數”操作產生的非重複值的準確或近似數量，則可分別設置 CountDistinctKeys 和 CountDistinctScale 屬性。
如果需要在數據流中創建多個聚合，應考慮使用一個聚合轉換而不是創建多個轉換來創建多個聚合。如果聚合是其他聚合的子集，這種方法能夠提高性能，因爲轉換可以優化內部存儲，並且只需掃描傳入的數據一次。例如，如果聚合使用 GROUP BY 子句和 AVG 聚合，將它們組合成一個轉換可以提高性能。但是，在一個聚合轉換內執行多個聚合會序列化聚合操作，因此，當必須獨立計算多個聚合時，這種方法可能不會改善性能。
有關詳細信息，請參閱聚合轉換。
模糊查找和模糊分組轉換
有關如何優化模糊查找和模糊分組轉換的性能的信息，請參閱白皮書：Fuzzy Lookup and Fuzzy Grouping in SQL Server Integration Services 2005（SQL Server Integration Services 2005 中的模糊查找和模糊分組轉換）。
查找轉換
通過輸入僅查找所需列的 SELECT 語句，最小化內存中引用數據的大小。這種方法優於選擇整個表或視圖，因爲後者將返回大量不必要的數據。
合併聯接轉換
合併聯接轉換包括 MaxBuffersPerInput 屬性，該屬性指定可以同時爲每個輸入處於活動狀態的最大緩衝區數。可以使用此屬性來優化緩衝區所使用的內存量，並由此優化轉換的性能。緩衝區數越大，轉換所使用的內存越多，性能越好。MaxBuffersPerInput 的默認值是 5，這是適合大多數工作情況的緩衝區數。若要優化性能，可能需要嘗試使用稍有不同的緩衝區數，例如，4 或 6。如果可能，應當避免使用非常小的緩衝區數。例如，將 MaxBuffersPerInput 設置爲 1 而不是 5，則可能對性能造成很大影響。另外，不應將 MaxBuffersPerInput 設置爲 0 或更小的值。此值範圍表示沒有中止發生，並且由於數據負載和可用內存數量，包可能無法完成。
若要避免死鎖，合併聯接轉換可能臨時增加它所使用的緩衝區數，使其超過 MaxBuffersPerInput 的值。死鎖條件消除之後，MaxBuffersPerInput 將返回它的配置值。
有關詳細信息，請參閱合併聯接轉換。
漸變維度轉換
漸變維度嚮導和漸變維度轉換是能滿足大多數用戶需要的通用工具。但是，該向導生成的數據流未針對性能進行優化。
通常，漸變維度轉換中最慢的組件是一次對單行執行 UPDATE 的 OLE DB 命令轉換。因此，改善漸變維度轉換性能最有效的方法是替換 OLE DB 命令轉換。可以用目標組件來替換這些轉換，目標組件將要更新的所有行保存到一個臨時表中。然後，可以添加執行 SQL 任務，該任務同時對所有行執行基於單集的 Transact-SQL UPDATE。
高級用戶可以爲漸變維度處理設計自定義數據流，此數據流將針對大型維度進行優化。有關此方法的討論和示例，請參閱白皮書 Project REAL: Business Intelligence ETL Design Practices（Project REAL：Business Intelligence ETL 設計實踐）中的章節 "Unique dimension scenario"（唯一維度方案）。
目標
若要改善目標的性能，請考慮使用 SQL Server 目標並測試目標的性能。
SQL Server 目標
當包將數據加載到同一計算機上的 SQL Server 實例時，請使用 SQL Server 目標。此目標針對高速大容量加載進行優化。
測試目標的性能
您可能會發現將數據保存到目標時所花的時間比預期的要長。爲了確定速度緩慢是否是由於目標處理數據的能力不足造成的，可以暫時將目標替換爲行計數轉換。如果吞吐量顯著提高，很可能是加載數據的目標導致速度減緩。
監視包的性能 Integration Services 包括可以用於監視包性能的工具和功能。例如，日誌記錄可以捕獲有關包的運行時信息，性能計數器則可以監視數據流引擎。請使用下列建議確定包中對性能影響最大的部分。
查看“進度”選項卡上的信息
SSIS 設計器提供有關在 Business Intelligence Development Studio 中運行包時控制流和數據流的信息。“進度”選項卡按執行順序列出任務和容器，而且還包括每個任務和容器及包自身的開始時間和結束時間、警告以及錯誤消息。它還按執行順序列出數據流組件幷包括進度信息（顯示爲完成百分比）和處理的行數。
若要允許或禁止在“進度”選項卡上顯示消息，請在 SSIS 菜單上切換“調試進度報告”選項。禁用進度報告有助於在 BI Development Studio 中運行復雜包時改進性能。
配置包中的日誌記錄
Integration Services 包括各種日誌提供程序，這些提供程序允許包在運行時將信息記錄到不同類型的文件中或記錄到 SQL Server 中。您可以爲包和各個包對象（例如任務和容器）啓用日誌項。Integration Services 包括各種任務和容器，每個任務和容器都具有其自己的一組說明性日誌項。例如，包括執行 SQL 任務的包可以寫入一個日誌項，列出該任務執行的 SQL 語句（包括該語句的參數值）。
這些日誌項包括諸如包和包對象的開始時間和完成時間這樣的信息，從而可以確定運行緩慢的任務和容器。有關詳細信息，請參閱記錄包執行的日誌、在包中實現日誌記錄和日誌記錄的自定義消息。
配置數據流任務的日誌記錄
數據流任務提供了許多可用於監視和調整性能的自定義日誌項。例如，您可以監視可能會導致內存泄漏的組件，或者跟蹤特定組件運行所用的時間。有關這些自定義日誌項的列表和日誌記錄輸出示例，請參閱數據流任務。
使用 PipelineComponentTime 事件
最有用的自定義日誌項可能是 PipelineComponentTime 事件。該日誌項報告數據流中的每個組件執行五個主要處理步驟中的每個步驟所用的毫秒數。下表對這些處理步驟進行了說明。Integration Services 開發人員應將這些步驟視爲 PipelineComponent 的主要方法。
|
步驟 |
說明 |
|---|---|
|
Validate |
該組件查看有效的屬性值和配置設置。 |
|
PreExecute |
該組件在開始處理數據行之前執行一次性處理。 |
|
PostExecute |
該組件在處理所有數據行之後執行一次性處理。 |
|
ProcessInput |
轉換或目標組件處理由上游源或轉換傳遞的傳入數據行。 |
|
PrimeOutput |
源或轉換組件填充數據緩衝區，以傳遞給下游轉換或目標組件。 |
啓用 PipelineComponentTime 事件時，Integration Services 將針對每個組件執行的各處理步驟記錄一則消息。以下日誌項顯示 Integration Services CalculatedColumns 包示例記錄的消息的子集。
“Calculate LineItemTotalCost”組件 (3522) 在 ProcessInput 中耗時 356 毫秒。
“Sum Quantity and LineItemTotalCost”組件 (3619) 在 ProcessInput 中耗時 79 毫秒。
“Calculate Average Cost”組件 (3662) 在 ProcessInput 中耗時 16 毫秒。
“Sort by ProductID”組件 (3717) 在 ProcessInput 中耗時 125 毫秒。
“Load Data”組件 (3773) 在 ProcessInput 中耗時 0 毫秒。
“Extract Data”組件 (3869) 在“OLE DB Source Output”輸出 (3879) 上的 PrimeOutput 填充緩衝區中耗時 688 毫秒。
“Sum Quantity and LineItemTotalCost”組件 (3619) 在“Aggregate Output 1”輸出 (3621) 上的 PrimeOutput 填充緩衝區中耗時 141 毫秒。
“Sort by ProductID”組件 (3717) 在“Sort Output”輸出 (3719) 上的 PrimeOutput 填充緩衝區中耗時 16 毫秒。
下列日誌項顯示數據流任務在下列步驟中消耗了大多數時間，如下所示（按降序排序）：
名爲“Extract Data”的 OLE DB 源在加載數據期間耗時 688 毫秒。
名爲“Calculate LineItemTotalCost”的派生列轉換在對傳入行執行計算期間耗時 356 毫秒。
名爲“Sum Quantity and LineItemTotalCost”的聚合轉換在執行計算和將數據傳遞到下一轉換期間共耗時 220 毫秒，其中有 141 毫秒用於 PrimeOutput，有 79 毫秒用於 ProcessInput。
監視數據流引擎的性能
Integration Services 包括一組性能計數器，用於監視數據流引擎的性能。例如，您可以跟蹤所有緩衝區使用的內存總量（以字節爲單位），並檢查組件是否內存不足。緩衝區是組件用於存儲數據的內存塊。有關詳細信息，請參閱監視數據流引擎的性能。