当我必须查看计划缓存/过度查询重新编译问题时,我遵循了Microsoft白皮书‘Plan Caching in SQL Server 2008’中提供的指导,我强烈建议您阅读它,因为它涵盖了计划缓存,查询计划重用,重新编译原因,识别重新编译和其他相关主题。因此,SQL Server Profiler(如果您将它安装为客户端工具安装的一部分,应位于Microsoft SQL Server 2008下的“性能工具”下)公开与查询编译直接相关的三个事件,这些事件可能有所帮助你:
您在使用存储过程,从而有可能你只需要担心SP:Recompile事件。只要重新编译存储过程,触发器或用户定义函数,此事件就会触发。 TextData列将显示导致语句重新编译的tsql语句的文本,而EventSubClass列将显示指示重新编译原因的代码。
为SP EventSubClass代码:重新编译在SQL 2008
- 1 =架构改变
- 2 =统计更改
- 3 =重新编译DNR
- 4 =设定选件已变更
- 5 =温度表更改
- 6 =远程行集更改
- 7 =对于浏览烫发改变
- 更改了8个
- 9 = MPI查看=查询通知环境的变化
- 10 =游标选项更改
- 11 =带重新编译选项
如果您监视以下5个事件可以查看哪些存储过程和语句正在SQL Server上调用,哪些正在触发重新编译:
个
- 存储过程的
- SP:启动
- SP:StmtStarting
- SP:重新编译
- SP:已完成
- 性能
我通常还会设置Profiler跟踪来捕获这些事件的所有列。我会说,用这5个事件设置一个跟踪,运行30到60秒的跟踪,然后暂停它,然后你应该有什么导致重新编译的快照。
如果噪声太多,您可以开始将列过滤器添加到跟踪属性以过滤输入/输出事件。例如,如果您发现大多数重新编译仅发生在一次数据库上,请在databaseID或databaseName列上设置列筛选器,以便在跟踪中包含针对该数据库运行的查询。
然后开始寻找重新编译查询的模式,并使用Microsoft的白皮书作为指导,说明为什么它们可能会触发重新编译。
非常有帮助,谢谢你,格伦。 – 2013-02-10 21:23:21