32

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

症状：

  • 执行时，数据流会获得通常的黄色“正在运行”图标。但是，当您双击查看数据流时，没有任何元素有任何黄色、红色或绿色标记。
  • 这种情况持续了很长时间，起初它持续了大约 20 分钟，之后它开始变得更长或根本没有返回。
  • 输出显示：
    信息：SSIS 加载沙箱表中的 0x40043006。管道：准备执行阶段开始。
    信息：加载沙箱表中的 0x40043007，SSIS.Pipeline：预执行阶段开始。
    在停止执行之前仅此而已。
  • 是的，这以前有效。是的，我们使用单个查询（在存储过程中）来执行此 ETL，但我们希望将所有步骤迁移到 SSIS。

    • 失败的解决方案：

  • 没有查找。
  • 任务流的默认缓冲区大小增加到 40485760，然后增加到 80971520。
  • 任务的默认缓冲区最大行数设置为 1000000。
  • 任务的延迟验证设置为 True。
  • 任务内的所有元素都设置为 Validate External Data 为 False。
  • 两个查询都有：
    SET FMTONLY OFF;
    设置无计数；
    在开始时添加。
  • 两个查询都将MAXDOP设置为 1。
  • 将项目的 Run 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 也得到验证并具有自己的延迟验证属性，需要将其设置为 true。
    之后，整个过程的执行时间从 40 多分钟或不运行到不到一分钟（这只是更大过程的一个步骤）
    我希望有同样问题的人可以轻松找到这个解决方案，因为有很多遇到这个问题的人几乎没有在线发布解决方案。

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

    4

    10 回答 10

    15

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

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

    于 2013-03-20T06:27:22.207 回答
    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 源中的视图中提取数据：

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

    2. 使用“SQL命令”访问方式，输入查询“select * from ***”

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

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

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

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

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

    感谢您为 SSIS 付出的时间、努力和支持。

    于 2017-10-31T15:58:51.757 回答
    5

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

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

    问候。

    于 2015-08-13T09:20:06.677 回答
    4

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

    于 2013-05-16T10:51:03.673 回答
    3

    我们已经将延迟验证设置为True并且不能/不想将其更改为 SQL 语句。
    我遇到ValidateExternalMetadata了我更改为的数据流，False它似乎工作得像个冠军。

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

    于 2017-03-13T20:02:09.147 回答
    2

    此问题在 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 服务器生成一个新的执行计划来解决我的问题。

    于 2017-12-27T14:54:52.087 回答
    1

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

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

    这里的一个线程向我提示了这个似乎有效的解决方案——尽管我的问题间歇性地出现，所以 YMMV。该线程中还有其他可能的解决方案。

    于 2013-12-03T10:30:42.607 回答
    1

    希望这可以帮助某人。我试图使用这个 OLE DB 源来执行带有参数的 SP。我不需要它来返回任何东西，所以我把那部分省略了。但它不让我，它大喊“sql没有返回列信息”。因此在我的 SP 中配置了一个虚拟 sql 语句，我将其设置为从不为真。但它从未将该列作为输出，并且该工作只是挂在执行前阶段。因此，我将该测试更改为始终为真，它返回了列，并且很快。我对专栏什么都不做，但我想那里需要它。

    于 2015-12-10T15:43:27.567 回答
    0

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

    于 2013-03-25T20:16:45.240 回答
    0

    在选择命令修复我的问题之前添加这个：

    set arithabort on;
    于 2022-02-16T18:13:57.883 回答