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

Question

我已经创建了一个ETL，它已经扩展到填充大约250个表(暂存表、维度表和事实表)。

我从Stacia Meisner那里得到了ETL设计模式，她的ETL设计模式是基于创建一个模板包来加载一个分期表，加载一个维度表，然后加载一个事实表。其思想是使用在特定包中设置的变量，然后调用适当的存储过程，创建沿袭和审核数据，使用表达式填充正确的表等，以便您只需在解决方案中复制和粘贴模板包，编辑变量，只要存储过程到位以来源数据和正确的表名，一切都会完美地工作。

那是..。直到我找到250张桌子。当我在投标中运行ETL时，它会疯狂地消耗RAM。当我部署ETL并在SQL中执行它时，它没有。在我的笔记本电脑上运行的ETL可能会消耗大约3到4G的RAM，因为它会从父包中打开我的每个子包。我的解决方案中现在有250个软件包。

我可以在我的笔记本电脑(目前坐在8GB或RAM)的RAM，但肯定有警告警报在我的头脑中，让我认为，也许250个数据流任务是一个更好的选择。

现在理解这种设计模式中的缺陷，我想我的问题如下

1. 投标是否意味着在ETL中执行这么多包？
2. 在IDE中运行ETL时，有什么方法可以减少RAM的消耗吗？
3. 内存的消耗是意料之中的，如果是的话，开发人员通常是如何处理的。我可以轻松地绕过它，永远不要在我的IDE中运行整个ETL，但是可以在它的各个部分中测试它，然后将它部署成完整的
4. 我是否应该离开每个表设计模式的一个包，在3个包中实现数据流任务(一个用于加载暂存表，一个用于加载维度，一个用于加载我的事实表)

谢谢您的时间，我会感谢您的意见。

致以敬意，

杰西

Answer 1

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

回到RAM:在ETL解决方案如此庞大的环境中，对于SSIS开发机器来说，8 gigs真的不是一个很大的数目--如果您可以选择升级，我认为这将是一个好主意。尽管我使用了一些相当大的ETL解决方案，但我还没有遇到您所描述的问题，但是我之前的两台开发机器拥有32 of和16 of的RAM。SSIS IDE还远远不够完善，我完全可以相信您所描述的是一个问题。

还必须指出，我并不经常在IDE中运行整个ETL解决方案。当我处理独立部件时，我更经常地运行它们，然后当我知道该部分正在工作时，我就会部署到一个开发环境(无论是本地安装还是服务器)，并通过代理完成我的完整运行。考虑到通过代理运行的方式与IDE内部的不同，我发现早期部署是有用的。我也很欣赏通过代理运行给我的日志信息--它可以帮助我跟踪我所做的更改是否影响了性能。使用2012+部署模型，以这种方式工作也不费时。

最终，我认为放弃有许多好处的固定模式，而不是稍微改变工作方式，以应对IDE的缺陷，这将是一个错误。我认为你在第3点可能已经回答了你自己的问题。

最后一个注意事项:如果您的笔记本电脑上有一个本地开发数据库(而不是仅在本地运行SSIS，而DB位于服务器上)，请确保本地SQL Server实例的最大RAM设置相当低。如果不这样做，它将使用所有的RAM来缓存东西，然后SQL Server和SSIS就会为RAM而战。我已经看到这会导致SSIS IDE中的内存错误。我不认为这是你在这里所描述的，但我提到它只是为了防止这有助于你，或其他人发现这个问答。

Answer 2

使用64位部署向导：

"C:\Program \Microsoft Server\xxx\DTS\Binn\ISDeploymentWizard.exe“