我们有一个用作 ETL 过程的生产 SSIS 解决方案。它已经投入生产一年多了，运行良好。然而，一夜之间，表演像石头一样下降。ETL 移动和处理的数据量没有显著差异。
ETL 过程是一系列非常简单的并行执行的单个包。它没有做任何特别复杂的事情。
没有向服务器部署任何内容，并且在上次"良好"运行和第一次"不良"运行之间没有进行任何配置更改，但突然之间花费了三倍于平时的时间。
我已经挖掘了日志，我想我可以看到发生了什么，但我不知道为什么。我查询了其中一个 SSIS 包的catalog.event_messages视图，发现包中的不同任务之间存在巨大的延迟。我看过许多其他软件包，并且重复了相同的模式 - 看起来它正在影响所有这些软件包。
当我将这些与前一天的条目(最后一次"良好"运行)进行比较时，没有延迟。这些包裹只是从头到尾快速浏览。
因此，看起来问题在于各种包中的任务之间突然引入这些延迟。
下面是一个示例。在最后的"良好"运行中，这个包从头到尾执行需要 <1 秒，但第二天晚上移动相同数量的数据大约需要 2 分钟。
2018-01-14 22:23:33.9631482 +00:00 EXTRACT_XXXXXXXXXX:Information: The package is attempting to configure from the parent variable "ProcessLogID".
2018-01-14 22:23:33.9631482 +00:00 EXTRACT_XXXXXXXXXX:Information: The package is attempting to configure from the parent variable "LoadID".
2018-01-14 22:24:02.7208761 +00:00 EXTRACT_XXXXXXXXXX:Validation has started.
2018-01-14 22:24:02.7208761 +00:00 EXTRACT_XXXXXXXXXX:Validation is complete.
...
...
所以第二行和第三行之间有 29 秒的差距
对于同一个软件包，再往下一点，我们有：
...
2018-01-14 22:24:02.8146315 +00:00 Truncate existing data:Start, 22:24:02.
2018-01-14 22:24:30.9061374 +00:00 Truncate existing data:Validation has started.
2018-01-14 22:24:30.9061374 +00:00 Truncate existing data:Validation is complete.
2018-01-14 22:24:46.6667393 +00:00 Truncate existing data:Finished, 22:24:46, Elapsed time: 00:00:43.844.
...
...
因此，启动此任务和验证之间有 28 秒的差距。
稍后我们还有：
...
2018-01-14 22:24:57.9902520 +00:00 Data Flow Task:Information: The final commit for the data insertion in "OLE DB Destination" has started.
2018-01-14 22:25:11.9929728 +00:00 Data Flow Task:Information: The final commit for the data insertion in "OLE DB Destination" has ended.
...
所以还有另一个很大的差距。
前一天晚上这个包的条目没有任何延迟(整个过程花了<1 秒)。
有没有人对可能导致这种情况的原因有任何想法？
在最后一次"好"和第一次"坏"运行之间没有新的部署/配置更改，因此没有任何变化(或至少没有明显的变化！
提前感谢您提供的任何帮助。
尝试使用以下命令更新数据库的统计信息：
EXEC sp_updatestats;
看起来您的包在验证阶段需要时间。请使用"Delay Validation=True"测试您的包以获取任务并查看结果。