SQL 服务器集成服务 - 内存不足异常
SQL Server Integration Services - Out of memory exception
我创建了一个 ETL，它已经增长到填充了大约 250 tables（登台表、维度表和事实表）。
我从 Stacia Meisner 那里得到了 ETL 设计模式，她的 ETL 设计模式是基于创建一个模板包来加载暂存 table、加载维度 table 然后加载事实table。这个想法是使用您在特定包中设置的变量，然后调用适当的存储过程，创建沿袭和审计数据，使用表达式填充正确的 tables 等，这样您只需复制并粘贴模板包在您的解决方案中，编辑变量，只要您有适当的存储过程来获取数据和正确的 table 名称，一切都会完美无缺。
也就是说...直到我达到 250 table 秒。当我 运行 BIDS 中的 ETL 时，它会疯狂地消耗 RAM。当我部署 ETL 并在 SQL 中执行它时，它没有。我笔记本电脑上的一个 ETL 运行 可能会消耗大约 3 到 4 GB 的 RAM，因为它从父包打开我的每个子包。我的解决方案中现在有 250 个包。
我可以增加笔记本电脑的 RAM（目前为 8GB 或 RAM），但我脑海中肯定响起警告警报，让我认为 250 个数据流任务可能是更好的选择。
现在了解了这个设计模式的缺陷，我想我的问题如下
- BIDS 是否意味着在一个 ETL 中执行这么多包？
- 当我 运行 IDE 中的 ETL 时，有什么方法可以减少 RAM 的消耗？
- 是否会消耗 RAM，如果是，开发人员通常如何处理它。我可以通过从不 运行 在我的 IDE 中使用整个 ETL 来轻松绕过它，而是对其进行部分测试，然后将其整体部署
- 我是否应该放弃每个 table 设计模式 1 个包并在 3 个包中实施数据流任务（1 个用于加载暂存 tables，1 个用于加载维度，1 个用于加载我的事实 tables)
感谢您的宝贵时间，非常感谢您的意见。
此致，
杰西
暂时不考虑 RAM 问题，我会保留设计模式。当您 运行 遇到只需要 运行 一个 table 的 ETL post 部署的情况时，它非常有价值。对于 2012+，它还为您提供了更多有用的日志记录信息，因为通过使用父包，它都被视为一个 运行 的一部分，允许您从 SSISDB 中保存的数据构建有用的 monitoring/reporting。您首先列出的采用此模式的所有其他原因也是有效的；该模式确实促进了重用和标准化，并减少了开发时间。它还使其他开发人员可以很容易地选择解决方案、找到解决方案、支持它、对其进行更改等。
回到 RAM：在 ETL 解决方案那么大的环境中，对于 SSIS 开发机器来说，8 GB 确实不是一个大数目 - 如果您可以选择升级，我认为这将是一个好主意。尽管使用了一些相当大的 ETL 解决方案，但我还没有 运行 解决您所描述的问题，但我之前的两台开发机器有 32GB 和 16GB 的 RAM。 SSIS IDE 远非完美，但我完全相信你所描述的是一个问题。
还必须注意的是，我并不经常 运行 IDE 中的整个 ETL 解决方案。我更经常 运行 独立的部分，因为我正在处理它们，然后一旦我知道该部分正在工作，我就会部署到开发环境（无论是本地安装还是服务器），并完成我的全部工作运行 通过代理。考虑到 运行 通过代理与 IDE 内部的不同，我发现尽早部署很有用。我也很感激 运行ning 通过代理给我的日志记录信息 - 它可以帮助我跟踪我所做的更改是否影响了性能。使用 2012+ 部署模型，以这种方式工作也不费时。
最终，我认为放弃具有许多好处的固定模式而不是稍微改变您的工作方式以应对 IDE 的缺陷是错误的。我认为您可能已经在很大程度上回答了第 3 点中您自己的问题。
最后一点：如果您的笔记本电脑上有一个本地开发数据库（而不是只在本地 运行ning SSIS，而数据库在服务器上），请确保您的最大 RAM 相当低本地 SQL 服务器实例的设置。如果你不这样做，它会使用你所有的 RAM 来缓存东西，然后 SQL 服务器和 SSIS 最终会争夺 RAM。我已经看到这会导致 SSIS IDE 中出现内存错误。我不认为这就是你在这里描述的内容，但我提到它只是为了以防万一这对你或其他找到此问答的人有所帮助。
我创建了一个 ETL，它已经增长到填充了大约 250 tables（登台表、维度表和事实表）。
我从 Stacia Meisner 那里得到了 ETL 设计模式，她的 ETL 设计模式是基于创建一个模板包来加载暂存 table、加载维度 table 然后加载事实table。这个想法是使用您在特定包中设置的变量，然后调用适当的存储过程，创建沿袭和审计数据，使用表达式填充正确的 tables 等，这样您只需复制并粘贴模板包在您的解决方案中，编辑变量，只要您有适当的存储过程来获取数据和正确的 table 名称，一切都会完美无缺。
也就是说...直到我达到 250 table 秒。当我 运行 BIDS 中的 ETL 时，它会疯狂地消耗 RAM。当我部署 ETL 并在 SQL 中执行它时，它没有。我笔记本电脑上的一个 ETL 运行 可能会消耗大约 3 到 4 GB 的 RAM，因为它从父包打开我的每个子包。我的解决方案中现在有 250 个包。
我可以增加笔记本电脑的 RAM（目前为 8GB 或 RAM），但我脑海中肯定响起警告警报，让我认为 250 个数据流任务可能是更好的选择。
现在了解了这个设计模式的缺陷，我想我的问题如下
- BIDS 是否意味着在一个 ETL 中执行这么多包？
- 当我 运行 IDE 中的 ETL 时，有什么方法可以减少 RAM 的消耗？
- 是否会消耗 RAM，如果是，开发人员通常如何处理它。我可以通过从不 运行 在我的 IDE 中使用整个 ETL 来轻松绕过它，而是对其进行部分测试，然后将其整体部署
- 我是否应该放弃每个 table 设计模式 1 个包并在 3 个包中实施数据流任务（1 个用于加载暂存 tables，1 个用于加载维度，1 个用于加载我的事实 tables)
感谢您的宝贵时间，非常感谢您的意见。
此致，
杰西
暂时不考虑 RAM 问题，我会保留设计模式。当您 运行 遇到只需要 运行 一个 table 的 ETL post 部署的情况时，它非常有价值。对于 2012+，它还为您提供了更多有用的日志记录信息，因为通过使用父包，它都被视为一个 运行 的一部分，允许您从 SSISDB 中保存的数据构建有用的 monitoring/reporting。您首先列出的采用此模式的所有其他原因也是有效的；该模式确实促进了重用和标准化，并减少了开发时间。它还使其他开发人员可以很容易地选择解决方案、找到解决方案、支持它、对其进行更改等。
回到 RAM：在 ETL 解决方案那么大的环境中，对于 SSIS 开发机器来说，8 GB 确实不是一个大数目 - 如果您可以选择升级，我认为这将是一个好主意。尽管使用了一些相当大的 ETL 解决方案，但我还没有 运行 解决您所描述的问题，但我之前的两台开发机器有 32GB 和 16GB 的 RAM。 SSIS IDE 远非完美，但我完全相信你所描述的是一个问题。
还必须注意的是，我并不经常 运行 IDE 中的整个 ETL 解决方案。我更经常 运行 独立的部分，因为我正在处理它们，然后一旦我知道该部分正在工作，我就会部署到开发环境（无论是本地安装还是服务器），并完成我的全部工作运行 通过代理。考虑到 运行 通过代理与 IDE 内部的不同，我发现尽早部署很有用。我也很感激 运行ning 通过代理给我的日志记录信息 - 它可以帮助我跟踪我所做的更改是否影响了性能。使用 2012+ 部署模型，以这种方式工作也不费时。
最终，我认为放弃具有许多好处的固定模式而不是稍微改变您的工作方式以应对 IDE 的缺陷是错误的。我认为您可能已经在很大程度上回答了第 3 点中您自己的问题。
最后一点：如果您的笔记本电脑上有一个本地开发数据库（而不是只在本地 运行ning SSIS，而数据库在服务器上），请确保您的最大 RAM 相当低本地 SQL 服务器实例的设置。如果你不这样做，它会使用你所有的 RAM 来缓存东西，然后 SQL 服务器和 SSIS 最终会争夺 RAM。我已经看到这会导致 SSIS IDE 中出现内存错误。我不认为这就是你在这里描述的内容，但我提到它只是为了以防万一这对你或其他找到此问答的人有所帮助。