2013-02-09 23 views
5

在我的SQL Server 2008标准版安装上跟踪性能监视器,我注意到SQL汇编/秒的峰值每五秒钟左右,3〜50左右如何确定什么是SQL Server的编译

我们也有相对较高的编译率与批量请求/秒。我理解这应该是1/10的比例,但我们的工作更像8/10。

db支持一个拥有大量应用程序的繁忙网站,所以很难确定是什么导致了过多的编译,尤其是5秒的高峰。几乎所有的查询都是存储过程调用而不是嵌入式SQL,而且我们有大量(48GB)RAM。

有没有办法在特定的时间查看当前正在编译的查询?如果是这样,我们可以确定是否有问题。

回答

6

当我必须查看计划缓存/过度查询重新编译问题时,我遵循了Microsoft白皮书‘Plan Caching in SQL Server 2008’中提供的指导,我强烈建议您阅读它,因为它涵盖了计划缓存,查询计划重用,重新编译原因,识别重新编译和其他相关主题。因此,SQL Server Profiler(如果您将它安装为客户端工具安装的一部分,应位于Microsoft SQL Server 2008下的“性能工具”下)公开与查询编译直接相关的三个事件,这些事件可能有所帮助你:

  • 光标
    • CursorRecompile
  • 性能
    • 显示计划XML查询编译
  • 存储过程
    • SP:重新编译

您在使用存储过程,从而有可能你只需要担心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的白皮书作为指导,说明为什么它们可能会触发重新编译。

+0

非常有帮助,谢谢你,格伦。 – 2013-02-10 21:23:21