首页 文章

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

提问于
浏览 次
21

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

Symptoms:

  • 正在执行时，数据流将获得通常的黄色"running"图标 . 但是，当您双击以查看数据流时，非元素具有任何黄色，红色或绿色标记 .

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

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

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

Failed solutions:

  • 没有查找 .

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

  • 任务的默认缓冲区最大行数设置为1000000 .
    对于该任务，

  • 延迟验证设置为True .

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

  • 两个查询都有：
    设置FMTONLY OFF;设置NOCOUNT ON;
    在开始时加入 .

  • 两个查询都将MAXDOP设置为1 .

  • 设置项目的运行64位运行时为False .

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

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

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

Extra bits: 我真的希望有人可以帮助我 . 我是SSIS的新手，这是我第一次使用它 . 我通常与Pentaho合作开发我的ETL，但客户需要在SSIS上实施解决方案 . 我've been battling with this issue for a couple of days now and I'米开始用尽解决问题的想法 .

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

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

之后它又冻结了 .

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

In a nutshell: 检查任务中涉及的所有元素，包括数据库连接是否将Delay Verification Property设置为True .

sql-server ssis etl

9 回答

  • 10

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

    In a nutshell: 检查任务中涉及的所有元素，包括数据库连接是否将Delay Verification Property设置为True .

    回复于
  • 0

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

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

    问候 .

    回复于
  • 1

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

    回复于
  • 1

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

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

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

    微软于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的时间，精力和支持 .

    回复于
  • 1

    显然，另一件事是检查“使用32位运行时”复选框 - 如果您在数据库服务器中运行程序包作为作业时遇到问题（这是64位，在我的情况下是至少，SQL Server 2008R2） . 转到作业，右键单击>属性...>步骤>右键单击SSIS包步骤>属性...>常规>执行选项（选项卡）>使用32位运行时 .

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

    一个帖子here给了我这个似乎有用的解决方案 - 尽管我的问题间歇性出现，所以YMMV . 该线程中还有其他可能的解决方案 .

    回复于
  • 4

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

    回复于
  • 3

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

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

    回复于
  • 0

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

    回复于
  • 3

    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服务器生成一个新的执行计划，为我解决了问题 .

    回复于

相关问题