SSIS 数据流任务在执行预执行阶段时挂起
Posted
技术标签:
【中文标题】SSIS 数据流任务在执行预执行阶段时挂起【英文标题】：SSIS Data Flow Task hangs on excecution of Pre-excecute phase 【发布时间】：2013-03-08 15:57:17 【问题描述】：我有一个正在执行的数据流任务。 流程很简单，对不同的表进行两次查询（都带有几个连接），然后通过一个公共 id 对输出进行排序和合并，为所有记录添加一个静态列，将行数保存在用户变量中以备后用使用并最终插入到另一个数据库上的表中。 我们正在使用 OLE DB 源和目标。源是 MSSQL 2000，目标是 MSSQL 2012 症状：
执行时，数据流会出现通常的黄色“正在运行”图标。但是，当您双击查看数据流时，没有任何元素有任何黄色、红色或绿色标记。 这种情况持续了很长时间，起初持续了大约 20 分钟，之后开始变长或根本不返回。 输出显示：信息：0x40043006 在加载沙箱表，SSIS。管道：准备执行阶段开始。 信息：加载沙箱表中的 0x40043007，SSIS.Pipeline：预执行阶段开始。 在停止执行之前仅此而已。 是的，这在以前有效。是的，我们使用单个查询（在存储过程中）来执行此 ETL，但我们希望将所有步骤迁移到 SSIS。失败的解决方案：
没有查找。 任务流的默认缓冲区大小增加到 40485760，然后增加到 80971520。 任务的默认缓冲区最大行数设置为 1000000。 该任务的延迟验证设置为 True。 任务内的所有元素都设置为“验证外部数据”为 False。 两个查询都有：SET FMTONLY OFF; SET NOCOUNT ON; 在开始时添加。 两个查询都将 MAXDOP 设置为 1。 将项目的 Run 64 位运行时设置为 False。 将目标加载从 Table 或 View 更改为 Table 或 View - 快速加载，没有锁定或约束。 将每批次的行数设置为 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 也得到验证并具有自己的延迟验证属性，需要将其设置为 true。 之后，整个过程的执行时间从 40 多分钟或不运行到不到一分钟（这只是更大过程的一个步骤） 我希望有同样问题的人可以轻松找到这个解决方案，因为有很多人遇到这个问题，而网上几乎没有任何解决方案发布。
简而言之：检查任务中涉及的所有元素，包括数据库连接的延迟验证属性设置为 True。
【问题讨论】：
如果您不在 Visual Studio 的上下文中运行它，会发生什么？从命令行，dtexec.exe /file C:\somepath\Package.dtsx
谢谢，我没想到。它再次卡住了，尽管输出看起来很奇怪。输出对于 cmets 来说太长了，我将编辑问题并将其添加到那里。
你能把输出的所有文字都贴出来吗？
当然！我正在编辑帖子
关于您的解决方案，我从未遇到过需要为数据库连接设置延迟验证为真的情况。不过，很高兴您的情况得到了解决。
【参考方案1】：
我终于明白了。 事实证明，验证存在问题，但不仅 SSIS 元素通过了验证，如问题的第四个失败解决方案中所述。 CONNECTIONS 也得到验证，并有自己的延迟验证属性，需要设置为 true。 之后，整个过程的执行时间从 40 多分钟或不运行到不到一分钟（这只是更大过程的一个步骤） 我希望有同样问题的人可以轻松找到这个解决方案，因为有很多人遇到这个问题，而网上几乎没有任何解决方案。
简而言之：检查任务中涉及的所有元素（包括数据库连接）是否已将延迟验证属性设置为 True。
【讨论】：
这只是我的 dtsx 需要滚动的后踢。在 Visual Studio 中调试时挂起 - 更改所有验证设置后，它工作得很好！【参考方案2】：我得到了相同的症状，但在每个组件上将延迟验证设置为 True 并没有解决我的问题。
我通过将 OLE DB 方法从表或视图更改为 sql 命令解决了这个问题。
问候。
【讨论】：
【参考方案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 源中的视图中提取数据：
使用“表或视图”访问方法
使用“SQL命令”访问方式，输入查询“select * from ***”
两种方法生成不同的执行计划。
前者使用的效率不如后者。
如果您在使用第一种方法时遇到性能问题，您可以切换到第二种方法作为解决方法。
我们也写了这个问题->http://blogs.msdn.com/sqlperf/archive/2007/04/29/set-up-ole-db-source-to-read-from-view-efficiently.aspx.
由于这是一个“按设计”项目，我们相信有一种解决方法，我们目前不会提供任何更改。因此，我们将关闭与您提交的相关案例。如果您不同意，请随时重新提交。
感谢您为 SSIS 付出的时间、努力和支持。
【讨论】：
【参考方案4】：通过将数据访问模式更改为 SQL 命令并将我的视图粘贴到 OLE DB 源中的 SQL 命令文本中解决了我的问题。
【讨论】：
【参考方案5】：我们已经将延迟验证设置为 True，但不能/不想将其更改为 SQL 语句。
我在数据流中遇到了ValidateExternalMetadata，我将其更改为False，这似乎很有效。
我检查了 OP 的步骤，他提到他们在第 5 步中这样做了
【讨论】：
【参考方案6】：此问题在 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 Server 生成一个新的执行计划来解决我的问题。
【讨论】：
我知道这个答案已经过时了，但您能否详细说明您添加了 1=1 的 OLE DB 源配置的哪一部分？ 那将在 SQL 语句本身中。更改 SQL 语句会强制执行新计划。不过，还有其他方法可以强制制定新计划【参考方案7】：显然，要尝试的另一件事是选中“使用 32 位运行时”复选框 - 如果您在数据库服务器（64 位，并且在至少我的情况是 SQL Server 2008R2）。转到作业，右键单击 > 属性... > 步骤 > 右键单击您的 SSIS 包步骤 > 属性... > 常规 > 执行选项（选项卡）> 使用 32 位运行时。
我看到了这个问题，但只有在我将包部署到服务器后（我启用了日志记录提供程序，所以我可以看到它在“预执行”阶段后卡住了）。它在 BIDS 中总是运行良好（在另一台服务器上运行良好，奇怪的是......仍然不确定为什么会这样）。
一个线程 here 向我介绍了这个似乎可行的解决方案——尽管我的问题间歇性地出现，所以 YMMV。该线程中还有其他可能的解决方案。
【讨论】：
这对我也有用 - 谢谢。这通常是解决方案！【参考方案8】：希望这对某人有所帮助。 我试图使用这个 OLE DB 源来执行带有参数的 SP。 我不需要它来返回任何东西，所以我把那部分省略了。 但它不让我，它大喊“sql没有返回任何列信息”。因此在我的 SP 中配置了一个虚拟 sql 语句，我将其设置为从不为真。 但它从未将该列作为输出，并且该工作只是挂在执行前阶段。因此，我将该测试更改为始终为真，它返回了列，并且很快。我对专栏什么都不做，但我想那里需要它。
【讨论】：
【参考方案9】：几分钟前我遇到了同样的问题，上面的建议对我不起作用（延迟验证 = true 似乎是答案）。我们最近发现了参数嗅探的一些问题，一旦我在我的存储过程中解决了这个问题，我的包在
【讨论】：
谢谢！实际上，我们删除了所有存储过程并为它们创建了 SSIS 步骤。但是我们的问题是通过延迟对连接而不是 SSIS 元素的验证来解决的。以上是关于SSIS 数据流任务在执行预执行阶段时挂起的主要内容，如果未能解决你的问题，请参考以下文章
Task.WaitAll在一个任务抛出时挂起，另一个任务与第一个任务同步