And*_*y W 6 sql-server sql-server-2008
在我的SQL Server 2008 Std Edition安装中跟踪性能监视器时,我注意到SQL Compilations/sec每5秒左右就会从3秒到大约50秒.
我们还有相对较高的编译率与批量请求/秒.我理解这应该是1/10的比例,但我们的工作更像是8/10.
数据库支持一个繁忙的网站,其中包含许多应用程序,因此很难确定造成过多编译的原因,特别是5秒的峰值.几乎所有的查询都是存储过程调用而不是嵌入式SQL,我们有大量的(48gb)RAM.
有没有办法在给定的时刻查看当前正在编译的查询?如果是这样,我们可以解决任何问题.
当我不得不在过去查看计划缓存/过度查询重新编译的问题时,我遵循了Microsoft白皮书"SQL Server 2008中的计划缓存"中提供的指导 ,我强烈建议您阅读它,因为它涵盖了计划缓存,查询计划重用,重新编译的原因,识别重新编译和其他相关主题.
话虽如此,SQL Server Profiler(应该位于Microsoft SQL Server 2008下 - >如果您将其作为客户端工具安装的一部分安装在Performance Tools中)会公开与查询编译直接相关的三个可能对您有所帮助的事件:
您正在使用存储过程,因此您可能只需要担心SP:重新编译事件.只要重新编译存储过程,触发器或用户定义的函数,就会触发此事件.TextData列将显示导致语句重新编译的tsql语句的文本,EventSubClass列将显示指示重新编译原因的代码.
SP的EventSubClass代码:在SQL 2008中重新编译
如果监视以下5个事件,您将能够看到在SQL Server上调用哪些存储过程和语句以及哪些存储过程和语句正在触发重新编译:
我还经常设置Profiler跟踪来捕获这些事件的所有列.我会说用这5个事件设置跟踪,运行跟踪30到60秒然后暂停它然后你应该有一个很好的快照导致重新编译.
如果噪声太大,您可以开始向跟踪属性添加列过滤器以过滤/输出事件.例如,如果您发现大多数重新编译只发生在一次数据库上,请在databaseID或databaseName列上设置列过滤器,以便只跟踪该数据库运行的查询.
然后开始查找正在重新编译查询的模式,并使用Microsoft的白皮书作为他们可能触发重新编译的原因的指南.
| 归档时间: |
|
| 查看次数: |
4739 次 |
| 最近记录: |