我正在从 Msft 论坛重新发布此内容，希望在这里获得更多回复。抱歉，如果这是不赞成的。...我目前正在考虑重构现有的大型 SSIS 2012 实现，该实现由大约 55 个项目和 360 多个包组成。正在使用的 ETL 框架有一个“主”控制包，它从数据库表中读取并确定哪些包准备好执行（基于一些依赖逻辑），然后在调用 dtexec 的循环中使用执行进程任务论据：
/C 启动 Dtexec /SQL "SomePackagePath" /SERVER "someserver"
这种设计允许循环执行一个包，然后立即迭代，因为它不等待包响应（也就是失败或成功完成），因此它可以在许多包准备执行时快速启动。SQL 代理作业用于每隔几分钟调用一次此包，以便它可以拾取自上次执行以来已满足其依赖关系的任何包并启动它们。
这是一个聪明的设计，但存在一些问题，例如分散的异常处理（因为父包不知道“异步”dtexec 调用中发生了什么。
我最担心的是，通过执行包，而不是使用执行包任务，而是使用执行进程任务，并启动许多 dtexec，框架没有利用 SSIS 处理所有正在运行的包和可执行文件的线程、内存消耗等的能力因为它根本不知道它们。它本质上就像使用 ExecuteOutOfProcess 属性设置为 true 的 Execute Package Task。
我想知道这种设计引入了多少风险，以及是否有任何方法可以将过度资源消耗的风险降至最低。对于这里没有确切的问题，我深表歉意，但非常感谢任何人可能提供的任何指导。