检测/监视参数嗅探问题

如何解决检测/监视参数嗅探问题

| 有什么工具可以专门监视/检测参数嗅探问题，而不是那些报告查询时间较长的工具？ 我刚遇到参数嗅探问题。 （它并不太严重，因为它导致报告运行大约需要2分钟，而如果正确缓存则需要花费几秒钟，而重新编译则可能需要30秒。而且由于该报告通常每月仅运行几次，因此并不是真正的问题）。 但是，由于我写了报告并且知道它做了什么，所以我很好奇并开始研究和使用SQL Profiler，我可以在查询计划中看到一个部分，其中估计的行数为1，而实际的行数为几十万 因此，令我震惊的是，如果SQL具有这些数字（或至少可以得到这些数字），也许有某种方法可以使sql跟踪并报告哪些计划被严重淘汰。     

解决方法

您在那里有几个问题： 有什么工具可以专门监视/检测参数嗅探问题，而不是那些报告查询时间较长的工具？ 为此，您需要监视过程高速缓存，以查明查询的执行计划何时从好变为坏。 SQL Server 2008通过向sys.dm_exec_query_stats中添加query_hash和query_plan_hash字段使此操作变得容易得多。您可以将同一查询_hash的当前查询计划与过去的查询计划进行比较，并在更改时，比较从旧查询到新查询的逻辑读取次数或工作时间。如果飞速发展，则可能是参数嗅探问题。 再说一次，有人可能刚刚删除了索引或更改了正在调用的UDF中的代码，或者更改了MAXDOP或影响查询计划行为的百万个设置中的任何一个。 您想要的是一个仪表板，该仪表板显示了总体上耗费资源最多的查询（因为您可能会在查询中遇到这个问题，该查询被调用得非常频繁，但每次都会消耗少量资源），然后显示您在随着时间的推移其执行计划，以及系统和数据库级别的更改。 Quest Foglight性能分析可以做到这一点。 （我曾经为Quest工作，所以我知道产品，但是我在这里先不卖。）请注意，Quest出售的另一产品Foglight与Performance Analysis无关。我不知道有任何其他产品可以提供这种详细信息。 我可以在查询计划中看到一个部分，其中估计的行数为1，但实际的行数为数十万。 不一定是参数嗅探-例如，可能是错误的统计信息或表变量用法。为了解决此类问题，我喜欢免费的SQL Sentry Plan Advisor工具。在“顶部操作”选项卡中，它突出显示了估计行与实际行之间的差异。 现在，一次只适用于一个计划，您必须首先了解该计划。您要24/7做这个，对不对？当然可以-但是它的计算量很大。过程高速缓存可能非常庞大（我的客户端具有大于100GB的过程高速缓存），并且全部都是未索引的XML。要比较估计的行与实际的行，您必须切碎所有XML-并记住过程高速缓存在负载下会不断变化。 您真正想要的是一种可以非常快速地将整个过程高速缓存转储到数据库中，在其上放置XML索引，然后将估计值与实际行进行比较的产品。我可以想象有一个脚本可以做到这一点，但是我还没有看到。     ,你说   \“估计的行数为1，但实际的行数为数十万。\” 这可能是由于没有统计信息的表变量引起的。 检测参数嗅探是困难的，但是您可以通过运行sp_updatestats来验证它是否正在发生。如果问题消失，则很可能是参数嗅探。如果不是，那么您还有其他问题，例如表变量太大 现在，我们始终如一地使用参数掩码（系统是在SQL Server 2000上开发的）。我们不需要99.9+％的时间，但是<0.1％可以证明它是合理的，因为它需要用户信心+支持开销。     ,您可以设置一个跟踪，以记录持续时间> Ns的所有批处理/存储过程的查询文本。 您显然需要为您的系统定制N（并且可能添加规则以排除即使在正常执行期间也要花费很长时间的批处理作业），但这应该确定哪些查询性能最差，并且还将记录所有查询（以及它们的参数） ）的执行时间异常长-可能是参数嗅探问题的结果。 有关如何使用T-SQL创建跟踪的信息，请参见如何使用T-SQL创建SQL跟踪。这将比使用SQL事件探查器提供更好的性能，因为它仅捕获您为其设置跟踪事件的事件（据报道，SQL事件探查器捕获所有事件，然后在应用程序中对其进行过滤）。