sql-server - 检测/监控参数嗅探问题

Question

是否有任何工具可以专门监视/检测参数嗅探问题，而不是报告需要很长时间的查询？

我刚刚遇到了参数嗅探问题。 (这并不是太严重，因为它导致报告需要大约 2 分钟才能运行，而不是如果正确缓存则需要几秒钟，如果重新编译则可能需要 30 秒。而且由于报告通常每月只运行几次，因此并不是真正的问题)。

但是，由于我写了报告并且知道它做了什么，所以我很好奇并开始调查并使用 SQL Profiler，我可以看到查询计划中的一个部分，其中估计行数为 1，但实际行数行数有几十万。

所以，我突然想到，如果 SQL 有这些数字(或者至少可以得到这些数字)，那么也许有某种方法可以让 SQL 跟踪和报告哪些计划明显超出了范围。

Answer 1

您有几个问题:

是否有任何工具可以专门监视/检测参数嗅探问题，而不是报告需要很长时间的查询？

要捕获此问题，您需要监视过程缓存以查明查询的执行计划何时从好变为坏。 SQL Server 2008 通过将 query_hash 和 query_plan_hash 字段添加到 sys.dm_exec_query_stats 使这变得更加容易。您可以将同一 query_hash 的当前查询计划与过去的查询计划进行比较，并且当它发生更改时，比较旧查询与新查询的逻辑读取次数或工作时间量。如果它猛增，则可能存在参数嗅探问题。

话又说回来，有人可能刚刚删除了索引或更改了正在调用的 UDF 中的代码，或者更改了 MAXDOP 或影响查询计划行为的一百万个设置中的任何一个。

您想要的是一个仪表板，它显示聚合中最消耗资源的查询(因为您可能会在调用极其频繁但每次消耗少量资源的查询上遇到此问题)，然后显示更改随着时间的推移，它的执行计划，加上系统和数据库级别的变化。 Quest Foglight Performance Analysis做这个。 (我曾经在 Quest 工作过，所以我了解这个产品，但我不在这里先卖钱。)请注意，Quest 销售一个单独的产品 Foglight，它与性能分析无关。我不知道有任何其他产品能达到如此详细的程度。

我可以看到查询计划中的一个部分，其中估计行数为 1，但实际行数为数十万。

这不一定是参数嗅探 - 例如，这可能是错误的统计数据或表变量使用情况。为了捕获此类问题，我喜欢免费的 SQL Sentry Plan Advisor工具。在“主要操作”选项卡中，它突出显示了估计行与实际行之间的差异。

现在，一次仅适用于一个计划，您必须首先了解该计划。你想 24/7 这样做，对吗？当然可以 - 但这是计算密集型的。过程缓存可能很大(我的客户端有 >100GB 的过程缓存)，而且都是未索引的 XML。要比较估计行与实际行，您必须分解所有 XML - 并记住过程缓存在负载下可能会不断变化。

您真正想要的是一种能够非常快速地将整个过程缓存转储到数据库中、在其上添加 XML 索引、然后将估计值与实际行进行比较的产品。我可以想象一个脚本可以做到这一点，但我还没有见过。