我已经创建了一个ETL，该ETL已成长为填充大约250个表（登台表，尺寸表和事实表）。
我从Stacia Meisner获得了ETL设计模式，她的ETL设计模式是基于创建用于加载分期表，加载尺寸表的模板软件包，然后加载事实表。这个想法是使用您在特定软件包中设置的变量，然后调用适当的存储过程，创建谱系和审核数据，使用表达式填充正确的表格等，以便您只需将模板包复制并粘贴到解决方案中，请编辑变量，只要您制定了存储过程以获取数据和正确的表名称，一切都可以完美地奏效。
那就是...直到到达250张桌子。当我以竞标方式运行ETL时，它会像疯狂一样消耗RAM。当我部署ETL并在SQL中执行它时，它不会。我的笔记本电脑上的一个ETL运行可能会消耗大约3至4千兆字节的RAM，因为它可以从父母包装中打开我的每个子包装。现在，我的解决方案中有250个软件包。
我可以在笔记本电脑中（目前坐在8GB或RAM）中抬起RAM，但是我脑海中肯定会发出警告警报，这使我认为大概250个数据流任务是一个更好的选择。
现在了解这种设计模式中的缺陷，我想我的问题如下
- 出价是否曾经在ETL中执行这么多包裹？
- 当我在IDE内运行ETL时，有什么办法可以减少RAM的消耗？
- 是可以预期的RAM的消费，如果是这样，开发人员通常如何处理它。我可以通过在我的IDE中运行整个ETL来轻松解决它，而是在其部分中测试它，然后将其部署在整个中
- 我应该远离每个表设计模式的1个软件包，并在3个软件包中实现数据流任务（1用于加载登台表，1用于加载尺寸，1用于加载我的事实表）
感谢您的时间，我感谢您的投入。
问：
jesse
逐渐离开RAM问题一段时间，我会保留设计模式。当您遇到只需运行一张桌子的ETL后部署的情况时，这是非常有价值的。借助2012 ，它还为您提供了更多有用的记录信息，因为通过使用父套件，它都被视为一项运行的一部分，从而使您可以从SSISDB中持有的数据中构建有用的监视/报告。您首先列出的所有采用此模式的其他原因也有效；该模式确实促进了重用＆amp;标准化并减少开发时间。这也使另一个开发人员很容易拿起解决方案，找到自己的方式，支持它，对其进行更改等。
回到RAM：8演出真的不是SSIS开发机器在您的ETL解决方案这么大的环境中的巨大数量 - 如果您可以选择升级，我认为这是一个好主意。尽管使用了一些非常大的ETL解决方案，但我并没有遇到您所描述的问题，但是我之前的两台开发机有32GB和16GB的RAM。SSIS IDE远非完美，我完全可以相信您描述的是一个问题。
还必须注意，我通常不会在IDE内运行整个ETL解决方案。我经常在处理它们的过程中运行独立零件，然后一旦我知道部分工作，我就会部署到开发环境（无论是本地安装还是服务器），并通过代理进行完整运行。鉴于事物通过代理与IDE内部运行的方式有所不同，我发现尽早部署很有用。我也感谢通过代理商给我运行的记录信息 - 它可以帮助我跟踪我所做的更改是否影响了性能。借助2012 部署模型，以这种方式工作也不耗时。
最终我认为，摆脱具有许多好处的坚实模式，而不是改变您的工作方式以应对IDE的缺陷是一个错误。我认为您可能已经在第3点回答了自己的问题。
最终注意：如果您的笔记本电脑上有本地开发数据库（而不是本地运行SSIS，并且DB在服务器上），请确保您的本地SQL Server实例具有相当低的最大RAM设置。如果您不这样做，它将使用所有RAM来缓存内容，然后SQL Server和SSIS最终会为RAM而战。我已经看到在SSIS IDE中导致内存错误。我不认为这是您在这里所描述的，但是我要提到的，以防万一对您有帮助，或者其他发现此Q＆amp; a。
使用64位部署向导：
; c： program Files Microsoft SQL Server xxx dts binn isDeploymentWizard.exe＆quote＆quote＆quort＆quort＆quort;