我可以看到我不是唯一遇到SSIS传输数据库对象任务和超时问题的人，但是，将其用于ETL提取阶段的人一定是相当普遍的，所以我正在尝试确定执行此操作的通常/可接受的方法。
我有一个使用实体框架生成 ~250 个表的 Web 应用程序，其中一些表偶尔会有架构更新。
ETL 的大部分转换和加载部分由一系列存储过程处理，但是，这些存储过程是从最初在"传输数据库对象"任务中加载的应用程序表的副本中读取的。
最初，我们设置了一个 SSIS 包，该包仅运行传输数据库对象任务，然后启动存储的过程。 这意味着作业对更改具有相当的弹性，并且唯一需要的更改是对存储过程的更改，如果架构更新影响其中使用的表。
遗憾的是，随着我们的一个应用程序实例随着时间的推移而增长，传输数据库对象任务达到了我经常看到超时错误的地步。 这些似乎不是连接超时，也不是我可以在服务器端控制的任何内容，而且从我所看到的情况来看，我无法修改该任务中底层SMO内容的CommandTimeout。
我可以看到有些人手动制作他们的数据提取，这样他们运行一个单独的数据流任务来从每个表中提取信息，这有一个明显的好处，即这些可以并行运行，但是，就我而言，这将意味着制作 250 个左右的初始工作块， 以及每当源数据库上的架构发生更改时维护任务，无论多么小。
我遇到了Biml，它看起来是一种至少可以减轻开销的可能方法，但是，这似乎还不能在VS2017上运行。
是否有人为此遵循任何特定模式，或者如果我确实需要单独的数据流任务，是否有某种方法可以自动执行架构更新，也许使用某种 SSIS 自动化和实体框架中的某些内容？
事实证明，解决此问题的最简单方法是编写传输任务的克隆，但要添加适当的内容以允许对批处理和超时等进行更多控制。 本文提供了详细信息：https://blogs.msdn.microsoft.com/mattm/2007/04/18/roll-your-own-transfer-sql-server-objects-task/