如何克服糟糕的 SSIS 调试性能？答案

【问题标题】：How do I overcome poor SSIS debugging performance?如何克服糟糕的 SSIS 调试性能？
【发布时间】：2008-10-31 14:59:22
【问题描述】：

我正在使用 SSIS 在两个数据库之间同步数据。我过去使用过 SSIS 和 DTS，但我通常为这种性质的事物编写应用程序（我是编码员，这对我来说更容易）。

在我的包中，我使用了一个返回大约 15,000 行的 SQL 任务。我已经将它连接到一个 Foreach 容器，并在其中将结果集列值分配给变量，然后将这些变量映射到提供给另一个 SQL 任务的参数。

我遇到的问题是调试，而不仅仅是更复杂的调试，例如断点和运行时评估值。我的意思是，如果我在调试而不是不调试的情况下运行它，则需要数小时才能完成。我最终在 Delphi 中重写了该过程，以下是我想出的：

全面推送数据：
这会提取 15,000 行，为每一行更新一个目标表，然后提取 11,000 行并为每一行更新一个目标表。

调试：
德尔福应用程序：139s
SSIS：4 小时 46 分钟

未调试：
德尔福应用程序：132s
SSIS：384s

数据更新：
这会提取 3,000 行，但不需要或对目标表进行更新。然后它会提取 11,000 行，但同样不需要或对目标表进行更新。

调试：
Delphi 应用程序：42 秒
SSIS：1 小时 10 分钟

未调试：
Delphi 应用程序：34 秒
SSIS：205s

奇怪的是，我感觉大部分时间都花在调试上，只是更新 Visual Studio 中的 UI 元素。如果我查看进度选项卡，每次迭代（总共数千个）都会将一个节点添加到树中，并且随着过程的进行，这会变得越来越慢。尝试停止调试通常不起作用，因为 Visual Studio 似乎陷入了更新 UI 的循环中。如果我检查 SQL Server 的探查器，则没有实际工作正在完成。我不确定这台机器是否重要，但它应该能胜任这项工作（四核、4 gig 内存、512 mb 显卡）。

这种行为正常吗？正如我所说，我是一名编码员，所以我为这类事情编写应用程序没有问题（事实上，我编写应用程序所需的时间比在 SSIS 中“绘制”它要少得多，但我认为随着在 SSIS 中完成更多工作，边距会缩小），但我试图找出像 SSIS 和 DTS 这样的东西适合我的工具箱的位置。到目前为止，没有什么让我真正印象深刻。也许我以某种方式误用或滥用了 SSIS？

任何帮助将不胜感激，在此先感谢！

【问题讨论】：

标签： delphi debugging ssis

【解决方案1】：

SSIS 控制流和循环的性能不是很高，并且不是为处理这些数据量而设计的。尤其是在调试期间 - 在每个任务执行之前和之后，调试器都会向设计进程发送通知，该进程会更新形状的颜色，这可能会很慢。

您可以使用数据流获得更好的性能。数据流不适用于单行，它适用于行缓冲区 - 速度更快，并且调试器只收到有关缓冲区开始/结束的通知 - 所以它的影响不太明显。

【讨论】：

【解决方案2】：

SSIS 的设计初衷不是为了做这样的 foreach。如果您正在为每一行进入，您可能希望将它们读入数据流，然后使用查找或合并连接，确定是执行 INSERT（这些是批量发生）还是执行多个 SQL UPDATE 的数据库命令对象命令（更好的执行选项是将这些批处理到临时表中并执行一次更新）。

在另一种典型的同步情况下，您将所有数据读入临时表，并对现有行执行 SQL Server UPDATE (INNER JOIN) 并在新行上执行 INSERT (LEFT JOIN, rhs IS NULL)。也有可能使用链接服务器，但连接可能会很慢，因为所有（或大部分）数据可能必须通过网络传输。

我有定期导入 2400 万行的 SSIS 包，包括处理数据转换和验证以及使用 TableDifference 组件缓慢更改维度，与单独的客户端程序相比，它对于大量数据的执行速度相对较快。

【讨论】：

【解决方案3】：

我注意到这是这种行为，我有一个用于移动的 SSIS 包，它在大约 300 万个条目附近的某个地方进行了调试，因为它会运行大约 3-4 天。

SSIS 仍然是我这样做的方式，我只是不使用 SSIS“调试”，而是在使用完整数据集时运行它们。如果我必须调试，我会使用非常小的数据集。

【讨论】：