为什么添加另一个 LOOKUP 转换会显着降低性能 SSIS答案

【问题标题】：Why adding another LOOKUP transformation slows down performance significantly SSIS为什么添加另一个 LOOKUP 转换会显着降低性能 SSIS
【发布时间】：2017-07-07 09:21:00
【问题描述】：

我有一个简单的 SSIS 包，可以在源和目标之间将数据从一台服务器传输到另一台服务器。

如果它的新记录 - 它插入，否则它检查 HashByteValue 列以及它是否与它的更新记录不同。

表包含大约 150 万行，并更新了大约 50 列。

当我开始调试包时，大约 2 分钟没有任何反应，我什至看不到绿色的复选标记。之后我可以看到数据开始流动，但有时它会停止，然后再次流动，然后再次停止，依此类推。

整个包长这样：

但如果我只做INSERT 部分（没有更新），那么它可以完美运行，1 分钟和目标表中的所有 150 万条记录。

那么为什么向更新记录的包添加另一个LOOKUP 转换会显着降低性能。跟记忆有关系吗？我在lookups 中都使用了FULL CACHE 选项。

提高性能的方法是什么？

原因可能在自动增长文件大小：

【问题讨论】：

如有疑问，请追踪！
将数据和日志的自动增长增加到 100MB，看看是否有帮助。 1MB 太小了。您很少会使用默认的 10% 进行自动增长。
我已经编辑了我的帖子。您可以看到数据库的自动增长。谢谢
是的，抱歉，我不小心删除了关于 AutoGrowth 的原始评论。但这似乎是您问题的一部分，这是肯定的。
运行包时，检查进度选项卡——它是否处于预执行阶段？这很可能是由于您要更新的目标数据的预取导致的延迟。它必须先将它们加载到内存中，然后才能将它们与您的源数据进行比较。

标签： sql-server ssis lookup

【解决方案1】：

我认为您的问题不在查找中。 OLE DB 命令在 SSIS 上真的很慢，我不认为它是为了大量更新行。在 MSDN 中查看这个答案：https://social.msdn.microsoft.com/Forums/sqlserver/en-US/4f1a62e2-50c7-4d22-9ce9-a9b3d12fd7ce/improve-data-load-perfomance-in-oledb-command?forum=sqlintegrationservices

要验证错误不是查找错误，请尝试禁用“OLE DB 命令”并重新运行该过程，看看需要多长时间。

根据我的个人经验，当您必须根据某些条件进行更新或插入时，最好创建一个存储过程来执行整个“数据流”。为此，您需要一个 Staging 表和一个 Destination 表（您将在其中加载转换后的数据）。

希望对你有帮助。

【讨论】：

我不知道为什么这个答案被否决了 - 它实际上回答了这个问题。 Gordon Bell 的备份响应（虽然完全正确）是切线. OLEDB cmd 执行逐行插入，oledb 目标，设置为快速加载执行相对更快的“批量”加载。而不是 cmd，您应该按照 asemprini87 的建议进行操作，并将更新行定向到临时表，然后调用 proc 来运行更新。
如果我错了请您纠正我...所以我有源表和目标表。您所说的是我应该将与 ID 匹配的行重定向到第三个（暂存）表。然后用SP更新它们？
通常 ETL 流程使用一个标准，您将查询放入数据源，然后将结果放入暂存表。在 Stage 中拥有数据后，您可以运行转换过程以将其放入 DataWarehouse。在此步骤中，您应该让 SP 执行此插入和更新。为此，我们专门在大型进程上使用临时表：en.wikipedia.org/wiki/Staging_(data)

【解决方案2】：

除了将 AutoGrowth 大小更改为 100MB 之外，您的数据库日志文件为 29GB。这意味着您很可能没有进行事务日志备份。

如果您不是，并且仅每晚或定期执行完整备份。将数据库的恢复模式从完全更改为简单。

数据库属性 > 选项 > 恢复模式

然后使用以下方法将您的日志文件缩小到 100MB：

DBCC SHRINKFILE(Catalytic_Log, 100)

【讨论】：

你是对的。我们刚刚在另一台服务器上创建了这个新实例，我们都不知道如何正确设置所有内容。谢谢
我在上面进行了编辑，向您展示了在设置为 Simple 后如何缩小日志文件。
好多好多好多好多好多好多好多好多！！！！在开始流动数据之前仍然等待一点，但是不到 2 分钟就完成了一切！！非常感谢！！！
太棒了，很高兴我能帮上忙。