查询计划中异常高的运营商成本的迹象？

Question

我有一个每月的 ETL 过程，太复杂了，在这里解释不了，但基本上我们获取大量客户数据，将其批量加载到各种表中，然后运行一系列构建过程。

总数据量很大，我们每个月增加25-30m记录到最大的表，总共有大约700m记录。每个都有 2m-300m 记录的支持表。该集合的总数据约为 3.5TB。

本月，某些流程所需的时间比平时长得多。一个例子是一个通常在 30 分钟内完成的过程，在我杀死它之前花了大约 40 小时（它仍然没有完成）。

并非所有进程都受到影响，有些进程甚至比平时运行得更快。

显然，根本原因超出了我在这里可以问的范围，但有一些事情困扰着我：

我们有实际的查询计划，以数百万% 显示单个运营商。

像对的聚簇索引扫描791,358,704%、对的合并连接75,566,494%等。这发生在多个查询计划中，而这些计划取自sys.dm_exec_query_plan。

这些查询计划是否表明了其他一些更大的问题？

我确信问题不是过时的统计数据 - 我们对所有主要表以及最大的表和数据库进行了全扫描，我手动重建了预先调整大小以消除碎片。

Answer 1

JNK,

你的意思是这样的？

这是根据客户端工具的统计信息生成的估计执行计划，请注意它不是引擎问题。如果您希望 MSFT 解决此问题，请为此连接项目投票。

由于您提到了 SQL Server 2008，我鼓励您在作业运行时查看 WAIT STATS 信息。看看为什么执行没有进展并找出瓶颈。

另外，查看 sys.virtualfilestats 信息，看看是否有明显的 IO 延迟以及内存使用情况。

HTH