SQL Server集成服务 - 内存不足异常

Question

我已经创建了一个已经增长到大约250个表（Staging Tables，Dimension Tables和Fact Tables）的ETL。

我从Stacia Meisner那里获得了ETL设计模式，她的ETL设计模式基于创建模板包来加载临时表，加载维度表，然后加载事实表。这个想法是使用您在特定包中设置的变量，然后调用相应的存储过程，创建沿袭和审计数据，使用表达式填充正确的表等，以便将模板包复制并粘贴到解决方案中，编辑该变量，只要你有存储过程来源数据和正确的表名，一切都完美。

这是......直到我达到250张桌子。当我在BIDS中运行ETL时，它会疯狂地消耗RAM。当我部署ETL并在SQL中执行它时，它不会。我的笔记本电脑上运行的一个ETL可能会消耗大约3到4 GB的RAM，因为它会从父包打开我的每个子包。我的解决方案中现在有250个软件包。我可以在我的笔记本电脑上（现在坐在8GB或RAM上）使用RAM，但是我的脑海中肯定会发出警告警报，这让我认为250个数据流任务可能是更好的选择。

了解缺陷在这种设计模式，现在，我想，那么我的问题如下

1. 当时BIDS曾经为了有一个ETL内执行这么多的包？
2. 当我在IDE中运行ETL时，有什么办法可以减少RAM的消耗？
3. 是否需要RAM的消耗，如果是的话，开发人员通常如何处理它。我可以很容易解决它，因为从不在我的IDE中运行整个ETL，但是在它的部分中测试它，然后全部部署它
4. 我应该逐步离开每个表设计模式的1个包并实施数据流任务3个包（1个用于加载临时表，1个用于加载尺寸，1个用于加载我的事实表）

感谢您的时间，我很感激您输入的内容。

问候，

杰西

Answer 1

步进从RAM问题，走了一会儿，我会继续的设计模式。当您遇到只需要运行一个表的ETL后期部署的情况时，它非常有价值。使用2012+，它还为您提供更多有用的日志信息，因为通过使用父包，它们都被认为是一次运行的一部分，允许您从SSISDB中保存的数据构建有用的监视/报告。首先你列出的采用这种模式的所有其他原因也是有效的;该模式确实促进了标准化的重复使用，并缩短了开发时间。这也使得其他开发人员很容易找到解决方案，找到解决办法，支持它，对其进行更改等。

回到RAM：8演出真的不是一个巨大的数量对于您的ETL解决方案非常重要的环境中的SSIS开发机器 - 如果您有升级选项，我认为这将是一个好主意。尽管我使用了一些相当大的ETL解决方案，但我还没遇到你所描述的问题，但是之前的两款开发机器都有32GB和16GB的RAM。尽管SSIS IDE远非完美，我完全可以相信你描述的是一个问题。

还必须注意的是，我并不经常在IDE中运行整个ETL解决方案。当我正在处理它们时，我经常运行独立部分，然后当我知道部分工作正常时，我将部署到开发环境（无论是本地安装还是服务器），并通过代理完成全部运行。考虑到通过代理与IDE内部运行的不同之处，我发现尽早部署它非常有用。我也很欣赏通过代理运行的日志记录信息 - 它可以帮助我跟踪我所做的更改是否影响了性能。采用2012+部署模式，以这种方式工作也不会耗时。

最终，我认为从具有许多好处的稳固模式转变为错误，而不是为了应对IDE的不完善而改变工作方式。我想你可能很大程度上在第3点回答了你自己的问题。

最后一点：如果你的笔记本电脑上有一个本地开发数据库（而不是只在本地运行SSIS，而数据库在服务器上）确定你的本地SQL Server实例的最大RAM设置相当低。如果你不这样做，它会使用你所有的内存来缓存内容，然后SQL Server和SSIS最终会争取内存。我已经看到在SSIS IDE中导致内存错误。我不认为这是你在这里描述的，但我提到它只是为了以防万一，这可以帮助你，或者其他人发现这一点。Q & A。