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

Question

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

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

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

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

整个包装看起来像这样：

但是如果我只做INSERT部分（没有更新）那么它在目的地表中完美地工作，1分钟和所有150万条记录。

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

提高绩效的方法是什么？

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

Answer 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

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

根据我的个人经验，最好创建一个存储过程来完成整个＆＃34;数据流＆＃34;当您必须根据特定条件更新或插入时。为此，您需要一个Staging表和一个Destination表（您将在其中加载转换后的数据）。

希望它有所帮助。

Answer 2

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

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

数据库属性＆gt;选项＆gt;恢复模式

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

DBCC SHRINKFILE(Catalytic_Log, 100)