是否有专门监控/检测参数嗅探问题的工具，而不是报告需要很长时间的查询的工具？
我刚刚遇到参数嗅探问题。 （它不是太严重，因为它导致报告需要大约2分钟才能运行而不是几秒钟如果正确缓存，如果重新编译可能需要30秒。而且因为报告通常每月只运行几次，所以不是真的有问题。）
然而，由于我编写报告并且我知道它做了什么，我很好奇并且正在调查并使用SQL事件探查器，我可以在查询计划中看到估计行数为1的部分，但实际数字行数是几十万。
所以，让我感到震惊的是，如果SQL有这些数字，（或者至少可以得到这些数字），也许有一些方法可以让sql跟踪并报告哪些计划显着。
答案 0 :(得分：3)
你有几个问题：
是否有专门监控/检测参数嗅探问题的工具，而不是报告需要很长时间的查询的工具？
要捕获这一点，您需要监视过程高速缓存以找出查询的执行计划何时从好变为坏。通过将query_hash和query_plan_hash字段添加到sys.dm_exec_query_stats，SQL Server 2008使这变得更加容易。您可以将当前查询计划与过去的查询计划进行比较，查询相同的query_hash，并在更改时，将旧查询中的逻辑读取次数或工作时间数量与新查询进行比较。如果它飞涨，你可能会有一个参数嗅探问题。
然后，有人可能刚刚删除了索引或更改了正在调用的UDF中的代码或更改了MAXDOP或影响查询计划行为的百万设置中的任何一个。
您想要的是一个统一显示资源消耗最多的查询的仪表板（因为您可能会在非常频繁地调用的查询中遇到此问题，但每次都会消耗少量资源），然后会向您显示它的执行计划随着时间的推移，加上系统和数据库级别的变化。 Quest Foglight Performance Analysis这样做。 （我曾经为Quest工作，所以我知道这个产品，但我不会在这里先令。）请注意，Quest销售的产品Foglight与Performance Analysis无关。我不知道任何其他产品都具有这种细节水平。
我可以在查询计划中看到估计行数为1的部分，但实际行数为数十万。
这不一定是参数嗅探 - 例如，可能是糟糕的统计数据或表变量使用情况。为了解决这类问题，我喜欢免费的SQL Sentry Plan Advisor工具。在“顶部操作”选项卡中，它突出显示估计行与实际行之间的差异。
现在，这只是一次只有一个计划，你必须先了解计划。你想24/7这样做，对吗？当然可以 - 但它是计算密集型的。过程缓存可能很大（我的客户端具有＆gt; 100GB的过程缓存），并且它都是未编入索引的XML。要比较估计行与实际行，您必须粉碎所有XML - 并且请记住，过程缓存可以在负载下不断变化。
您真正想要的是一种产品，它可以非常快速地将整个过程缓存转储到数据库中，在其上抛出XML索引，然后比较估计值与实际行数。我可以想象一个脚本这样做，但我还没有见过。
答案 1 :(得分：0)
你说
“估计行数为1，但实际行数为数十万。”
这可能是由没有统计信息的表变量引起的。
要检测参数嗅探很困难，但您可以通过运行sp_updatestats来验证它是否正在发生。如果问题消失，它很可能是参数嗅探。如果没有，那么您还有其他问题，例如表变量太大
我们现在一致地使用参数屏蔽（系统是在SQL Server 2000上开发的）。我们不需要99.9％以上的时间，但＆lt; 0.1％是合理的，因为它需要用户信心+支持开销。
答案 2 :(得分：-2)
您可以设置跟踪记录所有批次/存储过程的查询文本，其持续时间为＆gt;纳秒。
您显然需要为您的系统定制N（并且可能添加规则以排除即使在正常执行期间需要很长时间的批处理作业），但这应该确定哪些查询提供最差的性能并且还将记录任何查询（沿着它们的参数）具有异常长的执行时间 - 可能是参数嗅探问题的结果。
有关如何使用T-SQL创建跟踪的信息，请参阅How to create a SQL trace using T-SQL。这将提供比使用SQL事件探查器更好的性能，因为它只捕获您为其设置跟踪事件的事件（据报道，SQL事件探查器会捕获所有事件，然后在应用程序中过滤它们）。