SSIS数据流任务依赖于超前阶段的执行

Question

SSIS数据流任务依赖于超前阶段的执行

我有一个暂停执行的数据流任务.
流程很简单,对不同的表进行两次查询(两者都有几个连接),然后通过公共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.

任务中的所有元素都将Validate External Data设置为False.

两个查询都有:
SET FMTONLY OFF;
设置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

Run Code Online (Sandbox Code Playgroud)

之后它又冻结了.

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

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

Answer 1

Ryo*_*oku 13

我终于明白了.事实证明,验证存在问题,但不仅SSIS元素经过了验证,如第四个问题的失败解决方案中所述.CONNECTIONS也经过验证并具有自己的Delay Validation属性,需要将其设置为true.此后,excecution时间从40多分钟去或没有运行的全过程不到一分钟(这是一个更大的过程中只需一个步骤),我希望与这个同样的问题,人们可以很容易地找到这个解决方案,因为有很多遇到此问题的人几乎没有在线发布的解决方案.

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

Answer 2

小智 5

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

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

问候。

Answer 3

KyS*_*oto 5

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

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 源视图中提取数据：

使用“表或视图”访问方法

使用“SQL命令”访问方法，并输入查询“select * from ***”

两种方法生成的执行计划不同。

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

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

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

由于这是一个“按设计”的项目，并且我们相信有解决办法，因此我们目前不会提供任何更改。因此，我们将关闭与您提交的内容相关的案例。如果您不同意，请随时重新提交。

我们感谢您投入的时间、精力以及对 SSIS 的支持。

归档时间：	12 年，5 月前
查看次数：	48773 次
最近记录：	6 年，1 月前