跟蹤SSIS包中的數據加載性能問題

Question

有什麼方法可以確定數據庫中的差異是如何影響SSIS包加載性能的？

我有一個包加載並做處理各個位上〜100K記錄在我的筆記本電腦數據庫，約5分鐘

嘗試相同的封裝和相同的數據在測試服務器上，這是一個合理的它仍然在運行......大約1小時到目前爲止:-( 使用一小組數據檢查包，並且它運行通過Ok

Answer 1

CozyRoc了在MSDN forums我指出了正確的方向...
- 使用SSMS /管理/活動監控和發現大量交易的條目
- 它讓我想起，在OLE DB連接器和unchecked上閱讀起來表鎖
- WHAM ...數據加載罰款:-)

仍不明白爲什麼它可以在我的筆記本電腦d/b上正常工作，並在測試服務器上停止？
- 我是唯一一個使用d/b測試的人，所以它不是好像應該有任何爭用的表？

Answer 2

根據我的經驗，最大的性能因素SSIS是Network Latency。在服務器本地運行的程序包比網絡上的任何其他程序運行速度都快得多，除此之外，我不能爲什麼速度會有很大的不同。運行SQL Profiler幾分鐘可能會產生一些線索。

Answer 3

如果您排除了網絡延遲，最可能的罪魁禍首（具有實際數量的數據）就是您的管道組織。具體來說，你正在沿着這條管線做什麼轉變。

數據轉換進來四種口味：

• 流（完全在過程/內存）
• 無阻塞（但仍使用I/O，例如查找，OLEDB命令）
• 半阻塞（塊管道部分，但不完全，例如合併聯接）
• 阻斷（塊的流水線，直到它完全接收，例如排序，聚合）

如果您有一些阻止轉換，這將顯着地混淆在大型數據集上的性能。即使是半阻塞，在不平衡的輸入端，也會長時間阻塞。

Answer 4

我有類似的問題，在過去的幾周裏，這裏有幾件事情，你可以考慮，在根據什麼做出我們最大的不同重要性遞減的順序排列：

1. 唐't 假設關於服務器的任何事情。 我們發現我們的生產服務器的RAID配置錯誤（惠普向我們銷售了具有固件不匹配的磁盤），磁盤寫入速度實際上是它應該達到的50倍。因此，請使用Perfmon檢查服務器指標。

2. 檢查是否有足夠的RAM分配給SQL Server。插入大型數據集通常需要使用RAM和TempDB來構建索引等。確保SQL具有足夠的RAM，以便它不需要換出到Pagefile.sys。

3. 根據SSIS的聖盃，避免使用T-SQL語句操作大型數據集。即使您使用簡單恢復模式，所有T-SQL語句也會導致更改的數據寫入事務日誌。簡單恢復模式和完全恢復模式之間的唯一區別在於，每次事務處理後，Simple都會自動截斷日誌文件之後的。這意味着當使用T-SQL進行操作時，大數據集會衝擊日誌文件，從而導致性能下降。

4. 對於大型數據集，如果可能的話，會在源處進行數據排序。 SSIS排序組件扼殺了相當大的數據集，唯一可行的替代方案（Ordinal公司的nSort）每個CPU許可證不可轉讓的成本爲900美元。所以......如果你絕對需要一個大型的數據集，那麼考慮把它作爲中間步驟加載到臨時數據庫中。

5. ，如果你知道你的包是要在目標服務器上運行，因爲因爲它共享內存與SQL Server它提供了大致的性能提升15％，OLE DB使用SQL Server目標。

6. 將數據庫連接管理器上的網絡包大小增加到32767。這允許大量數據從源服務器移動得更快，並且可以顯着提高大數據集上的讀取。

7. 如果使用查找變換，實驗高速緩存大小 - 使用用於較小的數據集查找一個高速緩存連接或全部緩存模式之間，並部分/否緩存對於較大數據集。這可以釋放急需的RAM。

8. 如果組合多個大型數據集，使用RAW文件或臨時數據庫來保存您的轉化數據集，然後結合和插入一張表的所有數據在一個單一的數據流操作，並鎖定目標表。使用登臺表或RAW文件還可以幫助重新引導表鎖定爭用。

9. 最後但並非最不重要，實驗與DefaultBufferSize和DefaulBufferMaxRows屬性。您需要使用Perfmon.exe監視您的軟件包的「Buffers Spooled」性能計數器，然後調整緩衝區大小以上，直到看到緩衝區被假脫機（分頁到磁盤），然後退出一點。

8點是非常大的數據集尤爲重要，因爲如果你只能實現最低限度記錄容量插入操作：

• 目標表是空的，
• 鎖定表在加載操作期間。
• 數據庫處於簡單/批量日誌恢復模式。

這意味着下一代批量加載表總是會被完全記錄下來，因此您希望在第一次數據加載時獲取儘可能多的數據到表中。最後，如果您可以對目標表進行分區，然後將數據並行加載到每個分區，則加載時間可以達到2.5倍，儘管這通常不是一個可行的選項。