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