Question

我有一个暂停执行的数据流任务。
流程很简单，对不同的表进行两次查询（两者都有几个连接），然后通过公共id对输出进行排序和合并，为所有记录添加静态列，将行计数保存在用户变量中以供日后使用使用并最终插入到另一个DB上的表中。我们正在使用OLE DB源和目标。源是MSSQL 2000，目标是MSSQL 2012

症状：

执行时，数据流会获得通常的黄色“正在运行”图标。但是，当您双击以查看数据流时，非元素具有任何黄色，红色或绿色标记。

这种情况持续了很长一段时间，起初持续了大约20分钟，之后开始变长或根本没有返回。

输出显示：
信息：Load Sandbox Table中的0x40043006，SSIS.Pipeline：准备执行阶段开始。
信息：Load Sandbox表中的0x40043007，SSIS.Pipeline：预执行阶段正在开始。
除了停止执行之外别无其他。

是的，这之前已经奏效了。是的，我们使用单个查询（在存储过程中）来执行此ETL，但我们希望将所有步骤迁移到SSIS。

解决方案失败：

没有查找。

任务流的默认缓冲区大小增加到40485760，然后增加到80971520.

任务的默认缓冲区最大行数设置为1000000.

任务的延迟验证设置为True。

任务中的所有元素都设置为将外部数据验证为False。

两个查询都有：
SET FMTONLY OFF;
SET NOCOUNT ON;
在开始时添加。

两个查询都将 MAXDOP 设置为1。

将项目的运行64位运行时设置为False。

将目标负载从表或视图更改为表或视图 - 快速加载，没有锁定或约束。

将每批次的行数设置为1000以便快速加载。

一些解决方案建议将任务流分成两个或多个任务流。但这是不可能的，因为我们需要做的是合并两个源查询中的信息。

额外位： 我真的希望有人可以帮助我。我是SSIS的新手，这是我第一次使用它。我通常使用Pentaho为我的ETL工作，但客户需要在SSIS上实施解决方案。我已经和这个问题争斗了好几天了，而且我已经开始没有想法来解决这个问题了。

当通过命令行运行时，它也会卡住，我得到以下输出：

Progress: 2013-03-19 14:36:26.21
   Source: Load Sandbox Table
   Validating: 0% complete
End Progress
Progress: 2013-03-19 14:36:26.21
   Source: Load Sandbox Table
   Validating: 12% complete
End Progress
Progress: 2013-03-19 14:36:26.22
   Source: Load Sandbox Table
   Validating: 25% complete
End Progress
Progress: 2013-03-19 14:36:26.22
   Source: Load Sandbox Table
   Validating: 37% complete
End Progress
Progress: 2013-03-19 14:36:26.23
   Source: Load Sandbox Table
   Validating: 50% complete
End Progress
Progress: 2013-03-19 14:36:26.25
   Source: Load Sandbox Table
   Validating: 62% complete
End Progress
Progress: 2013-03-19 14:36:26.25
   Source: Load Sandbox Table
   Validating: 75% complete
End Progress
Progress: 2013-03-19 14:36:26.25
   Source: Load Sandbox Table
   Validating: 87% complete
End Progress
Progress: 2013-03-19 14:36:26.25
   Source: Load Sandbox Table
   Validating: 100% complete
End Progress
Warning: 2013-03-19 14:36:26.26
   Code: 0x80047076
   Source: Load Sandbox Table SSIS.Pipeline
   Description: The output column "ITEM_OID (1)" (47) on output "Merge Join Outp
ut" (28) and component "Merge Join" (11) is not subsequently used in the Data Fl
ow task. Removing this unused output column can increase Data Flow task performa
nce.
End Warning
Progress: 2013-03-19 14:36:26.27
   Source: Load Sandbox Table
   Prepare for Execute: 0% complete
End Progress
Progress: 2013-03-19 14:36:26.27
   Source: Load Sandbox Table
   Prepare for Execute: 12% complete
End Progress
Progress: 2013-03-19 14:36:26.27
   Source: Load Sandbox Table
   Prepare for Execute: 25% complete
End Progress
Progress: 2013-03-19 14:36:26.27
   Source: Load Sandbox Table
   Prepare for Execute: 37% complete
End Progress
Progress: 2013-03-19 14:36:26.27
   Source: Load Sandbox Table
   Prepare for Execute: 50% complete
End Progress
Progress: 2013-03-19 14:36:26.27
   Source: Load Sandbox Table
   Prepare for Execute: 62% complete
End Progress
Progress: 2013-03-19 14:36:26.27
   Source: Load Sandbox Table
   Prepare for Execute: 75% complete
End Progress
Progress: 2013-03-19 14:36:26.27
   Source: Load Sandbox Table
   Prepare for Execute: 87% complete
End Progress
Progress: 2013-03-19 14:36:26.27
   Source: Load Sandbox Table
   Prepare for Execute: 100% complete
End Progress
Progress: 2013-03-19 14:36:26.31
   Source: Load Sandbox Table
   Pre-Execute: 0% complete
End Progress
Progress: 2013-03-19 14:36:26.31
   Source: Load Sandbox Table
   Pre-Execute: 12% complete
End Progress
Progress: 2013-03-19 14:36:26.31
   Source: Load Sandbox Table
   Pre-Execute: 25% complete
End Progress
Progress: 2013-03-19 14:36:26.34
   Source: Load Sandbox Table
   Pre-Execute: 37% complete
End Progress
Progress: 2013-03-19 14:36:45.69
   Source: Load Sandbox Table
   Pre-Execute: 50% complete
End Progress

之后它又冻结了。

解决方案 （在此发布此消息因为我无法再回答我自己的问题5个小时，我会在允许的情况下执行此操作。） <登记/> 我终于明白了。
事实证明，验证存在问题，但不仅SSIS元素经过验证，如问题的第四个失败解决方案中所述。
CONNECTIONS也经过验证并具有自己的Delay Validation属性，需要将其设置为true。
之后，完成过程的执行时间从40多分钟或不运行到不到一分钟（这只是一个更大的过程的一步）
我希望有同样问题的人能够轻松找到这个解决方案，因为有很多人遇到这个问题而几乎没有解决方案在网上发布。

简而言之：检查任务中涉及的所有元素，包括数据库连接是否将Delay Verification Property设置为True。

Answer 1

我终于明白了。事实证明，验证存在问题，但不仅SSIS元素经过了验证，如第四个问题的失败解决方案中所述。 CONNECTIONS也经过验证并具有自己的Delay Validation属性，需要将其设置为true。之后，完成过程的执行时间从40多分钟或不运行到不到一分钟（这只是一个更大的过程的一步）我希望有同样问题的人能够轻松找到这个解决方案，因为有很多人遇到这个问题而几乎没有在线发布的解决方案。

简而言之：检查任务中涉及的所有元素，包括数据库连接是否将Delay Verification Property设置为True。

Answer 2

我有相同的症状，但在每个组件上将延迟验证设置为True并没有解决我的问题。

我通过将OLE DB方法从表或视图更改为sql命令来解决它。

问候。

Answer 3

我知道这是旧的，但我刚刚找到了一个可能有帮助的链接。我个人正在使用视图将数据导出到外部数据库，并且数据验证需要花费大量时间来验证视图。

https://connect.microsoft.com/SQLServer/feedback/details/258901/ssis-views-as-data-source-very-poor-performance-or-ssis-hangs

这一点的重要部分是微软的回答

Microsoft于2008年4月28日下午2:45发布

这是一个已知问题和当前设计的结果。

有两种方法可以从OLE DB源中的视图中提取数据：



使用＆＃34;表格或视图＆＃34;访问方法



使用＆＃34; SQL命令＆＃34;访问方法，然后输入查询＆＃34;从***＆＃34;

中选择*
在这两种方法中生成不同的执行计划。

前者使用的那种效率不如后者。

如果在使用第一种方法时遇到性能问题，可以切换到第二种方法作为解决方法。

我们还在博客中发布了此问题 - ＆gt; http://blogs.msdn.com/sqlperf/archive/2007/04/29/set-up-ole-db-source-to-read-from-view-efficiently.aspx。

因为这是一个“设计”。项目，我们相信有一项工作，我们目前不会提供任何变更。因此，我们将结束与您提交相关的案例。如果您不同意，请随时重新提交。

感谢您对SSIS的时间，精力和支持。

Answer 4

通过将数据访问模式更改为SQL命令并将我的视图粘贴到OLE DB源中的SQL命令文本来解决我的问题。

Answer 5

显然，要尝试的另一件事是检查“使用32位运行时”复选框 - 如果您在将数据包作为数据库服务器中的作业运行时遇到问题（这是64位，并且我的情况至少是SQL Server 2008R2）。转到作业，右键单击＆gt;属性...＆gt;步骤＆gt;右键单击您的SSIS包步骤＆gt;属性...＆gt;一般＆gt;执行选项（标签）＆gt;使用32位运行时。

我看到了这个问题，但只有一次我将软件包部署到服务器（我启用了日志服务提供程序，所以我可以看到它在“预执行”阶段后被卡住了）。它总是在BIDS中运行良好（在另一台服务器上很好，奇怪的是......仍然不确定为什么会这样）。

线程here向我倾斜了这个似乎有用的解决方案 - 虽然我的问题间歇性出现，所以YMMV。该线程中还有其他可能的解决方案。

Answer 6

希望这有助于某人。我试图使用此OLE DB源来执行带有参数的SP。我不需要它返回任何东西，所以我把那部分遗漏了。但它不会让我，它大喊'没有列信息由sql返回'。所以在我的SP中配置了一个虚拟sql语句，我将其设置为永不为真。但它从来没有将该列作为输出，而且工作只是挂在执行前阶段。因此，我将该测试更改为始终为真，它返回列，然后进行预测。我对该列没有任何作用，但我想那里需要它。

Answer 7

我们已将延迟验证设置为True并且无法/不想将其更改为SQL语句。
我在数据流中遇到了ValidateExternalMetadata，我将其更改为False，这似乎与冠军一样。

我检查了OP的步骤，他提到他们在第5步中已经这样做了

Answer 8

几分钟前我遇到了同样的问题，上面的建议对我没用（延迟验证=真似乎是回答）。我们最近发现了参数嗅探的一些问题，一旦我在我的存储过程中解决了这个问题，我的包运行于＆lt; 1分钟。请考虑检查存储过程以查看是否可能是原因。

Answer 9

SQL Server 2012/2014仍然存在此问题。

上述解决方案都没有帮助。实际上，没有任何改变延迟验证，更改OLD DB目标或OLE DB连接的配置。

从此链接中读取帖子：https://social.msdn.microsoft.com/Forums/sqlserver/en-US/35a484c7-4850-4f86-b14a-5dfb50491ab2/long-duration-preexecute-phase?forum=sqlintegrationservices

建议问题在于执行计划。

对于我的情况也是如此，并且在我的OLE DB源配置中添加条件1 = 1强制SQL服务器生成一个新的执行计划，为我解决了问题。

SSIS数据流任务在执行预执行阶段时挂起

9 个答案: