SSIS與DTS性能

太瘋狂了在這麼晚的日期在做這個，但是......SSIS與DTS性能

我重建了火箭軟件世界源和SQL目的地一些ETL基礎設施。舊的目標平臺是Windows Server 2003上的SQL 2000，新的平臺是Windows Server 2012上的SQL 2012.在這兩種情況下，都使用ODBC驅動程序連接到源。一切似乎都在新平臺上運行良好，但一個軟件包的執行時間呈指數級下降。例如，一個包含大約130萬行和28列的表使用SQL 2000/DTS需要大約一個小時，而使用SQL 2012/SSIS需要超過3.5小時。兩臺SQL服務器都在Xen Server上虛擬化，2012服務器擁有更多的RAM和更多的vCPU，這兩臺計算機在磁盤基礎架構上都沒有優勢。在包執行期間，沒有任何指標（內存，磁盤IO等）在2012服務器上發生紅線（甚至甚至接近）。

我已閱讀了幾篇論壇帖子，描述了相同的情況，但沒有一個真的似乎有一個解決方案，適合我。由於所有這些帖子都過時了（大多數從DTS到SSIS的這些轉換髮生在SQL 2005日期），所以我很好奇是否有更新的信息。

該軟件包非常簡單的表副本，沒有變換。我爲我的源連接使用了「SELECT column，column，.. FROM sourcetable」，爲我的目標使用了「Table或View - Fast Load」。儘管我無法確定，但是APPEARS放在等式的源端。

任何幫助表示讚賞。

來源

2013-05-31 stinkyP

對於仍在使用DTS的工作，您有我的哀悼;）也就是說，移除您當前的目標並將這些結果傳遞給腳本任務或可充當數據接收器而不會影響性能的東西可能會很有趣。目標是瞭解什麼是理論最大速率SSIS能夠從您的來源獲取數據。從服務器運行N次以建立基線。如果它與目的地的時間相當，那麼會很有趣...我的下一個地方是查看是否將緩衝區行數更改爲較低的值可以提高性能 – billinkc

文章談論緩慢SQL Server的方法來源http://sqlblog.com/blogs/rob_farley/archive/2011/02/17/the-ssis-tuning-tip-that-everyone-misses.aspx – billinkc

billinkc，我不知道我是如何獎勵你的，但是你是我今天的英雄，而現在我以一種勝利的感覺取代了失敗的週末到了週末！寧可反直覺地縮小緩衝區，但那是魔力子彈。下週我會做一些微調，但是將10,000行的默認值減少到10，可以將一個包的執行時間從平均一小時縮短到23分鐘，相當於舊的DTS時間。不夠感謝你！ – stinkyP

要調查的一個選項是降低數據流中的緩衝區大小。默認情況下，它被設置爲10k行。如果您的數據源很慢，則可能需要相當長的時間來填充「存儲桶」的數據，然後將一批信息發送到目的地。雖然這看起來可能違反直覺，但降低該數字可以提高性能，因爲5k或1k或100行數據可以更快地填滿存儲區。然後這些數據將通過數據流進行混洗，並在桶2，3等正在填充時落入源中。

如果你有一個SQL Server源代碼，你可以通過暗示你想要一個快速的N行來優化你的查詢，你需要對齊你的SSIS包的行大小。

有關更多詳情，請參閱Rob Farley's article。

來源

2013-06-01 00:44:25 billinkc

回答

相關問題