我刚刚遇到参数嗅探问题. (它不是太严重,因为它导致报告需要大约2分钟才能运行而不是几秒钟如果正确缓存,如果重新编译可能需要30秒.而且因为报告通常每月只运行几次,所以不是真的有问题).
但是,既然我写了报告并且我知道它做了什么,我很好奇并且正在调查并使用sql事件探查器,我可以在查询计划中看到估计行数为1的部分,但实际行数是几十万.
所以,让我感到震惊的是,如果sql有这些数字,(或者至少可以得到这些数字),那么也许有一些方法可以让sql跟踪并报告哪些计划显着.
解决方法
有没有专门监视/检测参数嗅探问题的工具,而不是报告需要很长时间的查询的工具？
要捕获这一点,您需要监视过程高速缓存以找出查询的执行计划何时从好变为坏.通过将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工具.在“顶部操作”选项卡中,它突出显示估计行与实际行之间的差异.
现在,这只是一次只有一个计划,你必须先了解计划.你想每周7天,每天24小时都这样做,对吧？当然可以 – 但它是计算密集型的.过程缓存可能很大(我的客户端具有大于100GB的过程缓存),并且它都是未编制索引的XML.要比较估计行与实际行,您必须粉碎所有XML – 并记住,过程缓存可以在负载下不断变化.
您真正想要的是一种产品,它可以非常快速地将整个过程缓存转储到数据库中,在其上抛出XML索引,然后将估计值与实际行进行比较.我可以想象一个脚本这样做,但我还没有见过.
