sql-server – SSIS数据流任务挂起了Pre-excecute阶段

发布时间：2020-12-12 16:35:50 所属栏目：MsSql教程来源：网络整理

导读：我有一个悬而未决的数据流任务. 流程很简单,对不同的表进行两个查询(两个连接都有两个连接),然后排序并通过公共ID合并otuputs,向所有记录添加静态列,将行计数保存在用户变量中以供以后使用使用并最终插入到另一个数据库的表中. 我们正在使用OLE DB Sources和D

我有一个悬而未决的数据流任务.
流程很简单,对不同的表进行两个查询(两个连接都有两个连接),然后排序并通过公共ID合并otuputs,向所有记录添加静态列,将行计数保存在用户变量中以供以后使用使用并最终插入到另一个数据库的表中.
我们正在使用OLE DB Sources和Destination.来源是MSSQL 2000,Destination是MSSQL 2012
症状：
>当excecuting时,数据流将获得通常的黄色“运行”图标.但是,当您双击以查看数据流时,不包含任何黄色,红色或绿色标记.
>这长时间持续了,起初它持续了大约20分钟,之后它开始变长了,根本就没有返回.
>输出显示：
信息：0x40043006在加载沙箱表,SSIS.Pipeline：准备执行阶段开始.
信息：0x40043007在加载沙箱表,SSIS.Pipeline：预执行阶段开始.
没有什么更多的,直到罢工被停止.

是的,这是以前的工作.是的,我们使用单个查询(在存储过程中)来执行此ETL,但是我们希望将所有步骤迁移到SSIS.

失败的解决方案：
>没有查找.
>任务流的默认缓冲区大小增加到40485760,然后增加到80971520.
>任务的默认缓冲区最大行设置为1000000.
>任务的Delay Validation设置为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分钟或没有运行到不到一分钟的时间(这只是一个更大的过程的一步)
我希望有同样问题的人可以很容易地找到这个解决方案,因为有很多人遇到这个问题,几乎没有在线发布解决方案.

简而言之：检查涉及任务的所有元素,包括数据库连接是否将延迟验证属性设置为True.

解决方法

我终于得到了
事实证明,正如问题的第四个失败的解决方案所述.
CONNECTIONS也得到验证,需要将其设置为true.
之后,完成时间从40分钟或没有运行到不到一分钟的时间(这只是一个更大的过程的一步)
我希望有同样问题的人可以很容易地找到这个解决方案,几乎没有在线发布解决方案.

简而言之：检查涉及任务的所有元素,包括数据库连接是否将延迟验证属性设置为True.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!