【问题标题】:SSIS - OLE DB Destination - Table or Views load vs. Fast-loadSSIS - OLE DB 目标 - 表或视图加载与快速加载
【发布时间】:2013-01-22 19:29:07
【问题描述】:

根据我的阅读:

表或视图数据访问模式将每一行作为一个事务一次提交。因此,让一个包传输 500 万行需要很长时间(30 多分钟)。

快速加载数据访问模式允许在插入到目标时指定批处理行和提交大小。例如,插入 500 万条记录只需 2 分钟多一点。

现在问题出现了,加载到 DW 的 SSIS 包之一在 OLE DB 目标中使用表或视图数据访问模式。据我了解,这是为了获取它插入的错误行(错误约束)到错误记录表中。因此,我们有一个需要 30 多分钟的过程。而对于相同的操作,Fast-Load 将花费不到 2 分钟的时间。

如果我理解正确,快速加载将无法区分哪一行导致批处理中的错误,进而导致批处理完全失败?如果是这样,是否有另一种方法来解决这种情况,即带有错误行的批次被错误约束重定向,然后以一种方式将批次中的好记录发送到正确的目的地,同时仍然发送错误记录到错误日志表中?这样做是个好主意吗?关于花费的时间,硬着头皮说话会更好吗?

提前谢谢你。

【问题讨论】:

    标签: ssis sql-server-2008-r2 data-warehouse


    【解决方案1】:

    我在这种情况下看到的做法是级联失败方法。在开始单例插入之前,尝试以连续较小的批次插入 OLE DB 目标,以尝试通过批处理模式获得尽可能多的数据。

    假设您的提交大小为 10k 行(任意数字、针对您的情况进行测试等)。将失败的行重定向到 OLE DB 目标,仍处于快速加载模式,但提交大小为 2.5k 行。添加另一个 ole db 目标,提交大小可能为 100,然后有一个处于 RBAR 模式的最终目标。然后,您可以识别失败的行并对它们执行任何需要执行的操作。

    【讨论】:

    • 我想知道为什么你不提交 X 行,如果有错误,不要让组件失败,而只是将错误行直接重定向到平面文件? - 见 El.HAM 的回答
    • @codeputer 我没有让组件失败。我们有相同的答案,只是术语不同。这个想法是您尝试以较大(有效)的规模提交,然后缩减为较小的部分。减少失败批次的原因是那里仍然有一些好的行,你不想把它们扔掉。最终引导行(平面文件、表等)的位置取决于 ETL 的体系结构
    • 我了解好的行,但是如果重定向失败的行,如果没有重定向的行,批处理会不会成功?
    【解决方案2】:

    好吧,我在 Fastload 模式下使用了一个目的地,并将其错误行重定向到另一个目的地,用于相同的 DestinationTable,但在逐行模式下。

    它没有 Row by Row 慢,也没有 Fastload 快,但它对我有用!
    我还有一个错误描述和真正的错误。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2020-01-26
      • 2015-01-02
      • 1970-01-01
      • 2016-11-16
      • 2016-09-28
      • 1970-01-01
      • 2015-06-01
      相关资源
      最近更新 更多