Performance 对于SSIS包来说，有多大太大？

在设计时或运行时性能受到影响之前，SQL Server 2005 SSIS包的定义可以有多大？我并不是说要传递的数据集的大小，甚至不是要返回的列数。我只是在讨论包中使用的序列、任务、数据流任务和变量的数量。我有一个包，我还不到实现的一半，我总共有20个序列（有些是嵌套的）、16个数据流任务和28个非数据流任务（大部分是执行SQL和脚本任务）。到目前为止.dtsx文件本身是4MB

---

当我完成的时候，我可以很容易地看到packge是当前大小的两倍甚至三倍。我还没有看到任何性能问题，但我想知道是否会遇到任何问题。是否有其他人遇到过大型包定义的设计时或运行时性能问题？对于包装尺寸限制是否有最佳实践

听起来是时候将该包分解为单独的包，并使用执行包任务来执行它们了。这太大了。

大型软件包会产生两个问题。@Andrew提到的第一个问题是，不管性能问题如何，都要维护一个大型包。特别是如果您在团队环境中工作，如果签出了一个大型包，则必须小心合并更改等。我在SQL 2005中看到的第二个问题与以下事实有关：BIDS中SSI的运行时是一个32位进程。对于像您提到的那样大的包，在您的开发环境中尝试执行该包时，很可能很快就会遇到内存不足的问题。大多数人建议将包分解成更小的单元，以简化团队开发和单元测试

下面是一篇知识库文章中的具体建议
这提到7mb是一个.dtsx大小，可能会引起问题

如上所述，根本原因是SSIS/BIDS的运行时（DevEnv.exe）是一个32位进程，其中的许多子系统创建了自己的私有堆，不会释放内存（xml、oledb等）。请参见对类似问题的回答：

---

我不确定什么太大，但对我来说，这些工具的继承问题是，你最终会看到一堆带有嵌入式对话框和属性的图形图片，这让你很快成为噩梦。如果你问我，没有什么比原始代码更好的了。你看到的就是你得到的。但是，要像对待原始代码那样，制作一些易于消化的小片段，并尽可能以最合乎逻辑的方式将它们拼凑在一起，这样您就可以将您的思想集中在它们周围。使用代码比使用SSI更容易做到这一点，但您仍然可以尝试这种类型的设计

---

因此，总而言之，如果软件包变得如此庞大和复杂，以至于你无法集中注意力，那么它就太大了。

我认为，无论性能如何，维护如此大的软件包都会带来重大问题。软件包仍处于初始开发阶段，尽管我一直在尝试对单个任务和包序列编写自动化的单元测试。当我不得不回去改变包裹的一部分时，这对我很有帮助。