改善資料流程的效能

MaxConcurrentExecutables 屬性是封裝本身的屬性。此屬性會定義可以同時執行多少工作。預設值為 -1，表示實體或邏輯處理器的數目加上 2。

若要了解此屬性的運作方式，請考慮具有三個「資料流程」工作的範例封裝。如果您將 MaxConcurrentExecutables 設定為 3，全部三個「資料流程」工作都可以同時執行。不過，這是假設每個「資料流程」工作都有 10 的來源到目的地的執行樹狀結構。將 MaxConcurrentExecutables 設定為 3 不能確保每個「資料流程」工作內的執行樹狀結構都可以平行執行。

EngineThreads 屬性是每個「資料流程」工作的屬性。此屬性會定義資料流程引擎可以平行建立並執行多少執行緒。EngineThreads 屬性同樣適用於資料流程引擎針對來源所建立的來源執行緒，以及該引擎針對轉換和目的地所建立的工作者執行緒。因此，將 EngineThreads 設定為 10 表示引擎最多可以建立 10 個來源執行緒與 10 個工作者執行緒。

若要了解此屬性的運作方式，請考慮具有三個「資料流程」工作的範例封裝。每個「資料流程」工作都包含 10 的來源到目的地的執行樹狀結構。如果您將「資料流程」工作上的 EngineThreads 設定為 10，全部 30 個執行樹狀結構可能會同時執行。

某些資料流程元件會在從來源擷取資料時或在查閱作業中使用查詢，以建立參考資料表。預設查詢會使用 * FROM <tableName> 語法。這種類型的查詢會傳回來源資料表中的所有資料行。讓所有資料行都在設計階段可用，您便可以選擇任何資料行作為查閱、傳遞或來源資料行。不過，在選擇要使用的資料行後，您應該將查詢修訂為只包含選取的資料行。移除多餘的資料行可讓封裝中的資料流程更為有效，因為資料行越少，就會建立越小的資料列。資料列越小，表示有越多的資料列可以納入同一個緩衝區，而且處理資料集中全部資料列所需的工作也就越少。

若要建構查詢，您可以輸入查詢或使用「查詢產生器」。

排序本質上就是很慢的作業，避免不必要的排序可以改善封裝資料流程的效能。

有時候來源資料在由下游元件使用前，就已經經過排序。這種預先排序會在 SELECT 查詢使用 ORDER BY 子句時，或在將資料以排序的順序插入來源時發生。對於這種預先排序的來源資料，您可以提供資料已排序的提示，因而避免使用「排序」轉換來滿足某些下游轉換的排序需求 (例如，「合併」和「合併聯結」轉換需要已排序的輸入)。若要提供資料已排序的提示，您必須執行下列工作：

• 將上游資料流程元件之輸出的 IsSorted 屬性設定為 True。

• 指定排序資料所依據的排序索引鍵資料行。

如需詳細資訊，請參閱＜如何：排序合併和合併聯結轉換的資料＞。

如果在資料流程中必須排序資料，您可以將資料流程設計為盡可能少使用排序作業，以改進效能。例如，資料流程使用「多點傳送」轉換來複製資料集。在「多點傳送」轉換執行前，對資料集進行一次排序，而不應在轉換後排序多個輸出。

如需詳細資訊，請參閱＜排序轉換＞、＜合併轉換＞、＜合併聯結轉換＞和＜多點傳送轉換＞。

當您使用 OLE DB 來源從檢視表中擷取資料時，選取 [SQL 命令] 當做資料存取模式，然後輸入 SELECT 陳述式。使用 SELECT 陳述式存取資料的效能比選取 [資料表或檢視表] 當做資料存取模式的效能更好。

「彙總」轉換包括 Keys、KeysScale、CountDistinctKeys 和 CountDistinctScale 屬性。這些屬性會提升效能，其方式是讓轉換針對轉換所快取的資料來預先配置所需的記憶體數量。如果您知道預期要從 [群組依據] 作業產生的精確或大約群組數，請分別設定 Keys 和 KeysScale 屬性。如果您知道預期要從 [相異計數] 作業產生的精確或大約相異數，請分別設定 CountDistinctKeys 和 CountDistinctScale 屬性。

如果必須在資料流程中建立多個彙總，您應考慮使用一個「彙總」轉換來建立多個彙總，而不是建立多個轉換。當一個彙總就是其他彙總的子集時，這個方法能夠改善效能，因為轉換可以最佳化內部儲存體，並且只會掃描一次傳入的資料。例如，如果彙總使用 GROUP BY 子句和 AVG 彙總，則將它們組合成一個轉換可以改進效能。不過，在一個「彙總」轉換內執行多個彙總會序列化彙總作業，因此，當多個彙總必須個別計算時，可能不會改善效能。

如需詳細資訊，請參閱＜彙總轉換＞。

如需有關最佳化「模糊查閱」和「模糊群組」轉換的詳細資訊，請參閱 SQL Server Integration Services 2005 中的模糊查詢和模糊群組白皮書。

輸入僅查閱所需資料行的 SELECT 陳述式可以將記憶體中的參考資料大小最小化。這個選項的效能比選取會傳回大量不必要資料的整個資料表或檢視表更好。

合併聯結轉換包括 MaxBuffersPerInput 屬性，用以指定每一次輸入時所容許的使用中緩衝區數目上限。您可以使用這個屬性來微調緩衝區使用的記憶體數量，並進而微調轉換的效能。緩衝區的數目愈大，轉換使用的記憶體就愈多，效能也會愈高。MaxBuffersPerInput 的預設值 5 是多數案例中能夠達到最佳效果的緩衝區數目。若要微調效能，您可以嘗試使用稍有不同的緩衝區數目，例如 4 或 6。如果可能，您應該避免使用過小的緩衝區數目。例如，將 MaxBuffersPerInput 由 5 改設為 1 會對效能造成重大影響。同時，您不應將 MaxBuffersPerInput 設定為 0 (包含) 以下。這個值範圍表示不會進行調整，而且依據資料負荷量和可用的記憶體數量而定，封裝可能會不完整。

為了避免發生死結，合併聯結轉換可能會暫時增加其所使用的緩衝區數目，使其超過 MaxBuffersPerInput 的值。解決死結狀況之後，MaxBuffersPerInput 便會回復成原先的設定值。

如需詳細資訊，請參閱＜合併聯結轉換＞。

「緩時變維度精靈」和「緩時變維度精靈」轉換都是符合多數使用者需求的一般用途工具。不過，精靈所產生的資料流程不會針對效能進行最佳化。

「緩時變維度」轉換中最緩慢的元件通常是一次針對一個單一資料列執行 UPDATE 的「OLE DB 命令」轉換。因此，改善「緩時變維度」轉換效能最有效的方式就是取代「OLE DB 命令」轉換。您可以將這些轉換取代為將要更新的所有資料列儲存到臨時資料表的目的地元件。然後，您可以同時加入針對所有資料列執行以單一資料列集為基礎之 Transact-SQL UPDATE 的「執行 SQL」工作。

進階使用者可以針對緩時變維度處理，設計針對大維度進行最佳化的自訂資料流程。如需此方式的討論和範例，請參閱專案 REAL：Business Intelligence ETL 設計練習白皮書中的「唯一的維度狀況」一節。

當封裝將資料載入相同電腦上的 SQL Server 執行個體時，請使用 SQL Server 目的地。這個目的地最適合高速大量載入。

您可能會發現將資料儲存至目的地所花費的時間超出預期。若要識別速度很慢是否是因為目的地無法夠快地處理資料，您可以暫時使用「資料列計數器」轉換來取代目的地。如果輸送量顯著提高，則很可能是正在載入資料的目的地導致速度變慢。

最有用的自訂記錄項目可能是 PipelineComponentTime 事件。這個記錄項目會報告每個元件在五個主要處理步驟的每個步驟中所花費的毫秒數。下表將描述這些處理步驟。Integration Services 開發人員會將這些步驟辨識成 PipelineComponent 的主要方法。

當您啟用 PipelineComponentTime 事件時，Integration Services 就會針對每個元件所執行的每個處理步驟記錄一則訊息。下列記錄項目會顯示 Integration Services CalculatedColumns 封裝範例所記錄的訊息子集：

The component "Calculate LineItemTotalCost" (3522) spent 356 milliseconds in ProcessInput.

The component "Sum Quantity and LineItemTotalCost" (3619) spent 79 milliseconds in ProcessInput.

The component "Calculate Average Cost" (3662) spent 16 milliseconds in ProcessInput.

The component "Sort by ProductID" (3717) spent 125 milliseconds in ProcessInput.

The component "Load Data" (3773) spent 0 milliseconds in ProcessInput.

The component "Extract Data" (3869) spent 688 milliseconds in PrimeOutput filling buffers on output "OLE DB Source Output" (3879).

The component "Sum Quantity and LineItemTotalCost" (3619) spent 141 milliseconds in PrimeOutput filling buffers on output "Aggregate Output 1" (3621).

The component "Sort by ProductID" (3717) spent 16 milliseconds in PrimeOutput filling buffers on output "Sort Output" (3719).

這些記錄項目顯示資料流程工作將大部分時間花費在下列步驟上 (在此依遞減順序顯示)：

• 名為 "Extract Data" 的 OLE DB 來源花費了 688 毫秒來載入資料。

• 名為 "Calculate LineItemTotalCost" 的「衍生的資料行」轉換花費了 356 毫秒來計算傳入資料列。

• 名為 "Sum Quantity and LineItemTotalCost" 的「彙總」轉換花費了結合的 220 毫秒 (141 毫秒在 PrimeOutput 而 79 毫秒在 ProcessInput) 來執行計算以及將資料傳遞給下一個轉換。