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