SQL Server 2005 SSIS包定義在設計時或運行時性能受到影響之前會變得多大？我不是在談論正在傳遞的數據集的大小，甚至是正在返回的列數。我只是談論包中使用的序列，任務，數據流任務和變量的數量。我有一個包，我還沒有完成一半的實現，並且我總共有20個序列（一些嵌套），16個數據流任務和28個非數據流任務（主要是執行SQL和腳本任務） 。 .dtsx文件本身目前爲4MB。SSIS包裝有多大？
當我完成的時候，我可以看到packge容易加倍，甚至是目前的三倍。我還沒有看到任何性能問題，但我想知道我是否會遇到任何問題。是否有其他人遇到大包定義的設計時或運行時性能問題？包裝尺寸限制是否有最佳做法？
聽起來好像是時候讓你把這個軟件包分解成單獨的軟件包，然後使用Execute Package Task執行它們。這太大了。
大包裝出現兩個問題。 @Andrew提到的第一件事是不管性能問題如何維護一個大型軟件包。特別是如果你在團隊環境中工作，如果你簽出了一個大包，你將不得不小心合併更改等。我在SQL 2005中看到的第二個問題與事實有關BIDS中的SSIS運行時是32位進程。使用與您所提到的一樣大的軟件包，很可能在嘗試在開發環境中執行該軟件包時很快就會遇到內存不足的問題。大多數人建議將軟件包分成更小的單元來簡化團隊開發和單元測試。
這裏是一個知識庫文章 http://support.microsoft.com/kb/952110/en-us
是7MB提到作爲一個.dtsx程序大小，可以開始引起問題的具體建議。
如上所述，根本原因在於SSIS/BIDS（DevEnv.exe）的運行時是32位進程，該exe中的許多子系統創建自己的私有堆，不釋放內存（xml，oledb等），看到這個響應類似的問題：
http://social.msdn.microsoft.com/forums/en-US/sqlintegrationservices/thread/7ead0bee-6f04-4778-83b7-0fd666833113/
我不知道什麼是太大，但對我的繼承問題，這些類型的工具是你最終的圖形畫面一團糟嵌入式對話和屬性匆忙地做出噩夢。如果你問我，沒有什麼比原始代碼更勝一籌。你所看到的就是你得到的。然而，做一個用原始代碼做的事情，製作一些易消化的小塊，並以最合乎邏輯的方式將它們拼湊在一起，這樣你就可以將自己的思想包裹在它們周圍。使用代碼比SSIS更容易做到這一點，但您仍然可以嘗試這種類型的設計。
所以總而言之，如果包裝變得如此龐大而複雜，你無法圍繞它包裝，它太大了。
我會認爲維護一個尺寸會導致明顯問題的軟件包，無論性能如何。 – Andrew 2010-02-21 16:10:31
這個軟件包還處於初始開發階段，儘管我一直在嘗試在單個任務和程序包的序列上編寫自動化單元測試。當我必須返回並更改包的一部分時，這幫助了我。 – virsum 2010-02-23 13:50:58