SQL Server 2005性能测试之CPU篇（编译与重编译）

核心提示： 在SQL Server 2000中，当SQL Server重新编译一个存储过程时，SQL Server 2005性能测试之CPU篇（编译与重编译）(2)，整个存储过程都会被重编译，而不只是触发重编译的语句，然而，当一个存储过程被重新编译时，SQL Server 2005引入了一种语句级别重

在SQL Server 2000中，当SQL Server重新编译一个存储过程时，整个存储过程都会被重编译，而不只是触发重编译的语句。SQL Server 2005引入了一种语句级别重编的存储过程。当SQL Server 2005重新编译存储过程时，只有引起重编译的语句才会被编译而不是整个过程。这就减少了CPU带宽并且减少了资源锁出现的可能，例如：COMPLIE locks. 重编译可以由于很多不同的原因造成，如：

◆架构变化

◆统计变化

◆延期编译

◆SET选项变化

◆临时表变化

◆存储过程以RECOMPLIE选项建立。

检测

使用System Monitor 或者 SQL Server Profiler来检测过多的编译和重编译。

System Monitor

SQL Statistics对象提供计数器来监视编译和发送到SQL Server实例的请求类型。必须通过监视查询编译和重编译的数量结合接收到的批处理数量来找出高CPU消耗是否是由编译引起。理想情况下，SQL Recompilations/sec和Batch Requests/sec的比率应该应该非常低，除非用户提交的是即席查询。

以下是关键数据计数器：

◆SQL Server: SQL Statistics: Batch Requests/sec

◆SQL Server: SQL Statistics: SQL Compilations/sec

◆SQL Server: SQL Statistics: SQL Recompilations/sec

SQL Trace

如果性能计数器显示非常大的重编译数量，重编译可能正在造成高CPU消耗。接下来需要需要利用SQL Profiler纪录的trace来找出当时被重新编译的存储过程。SQL Server Profiler trace可以给出这些信息连同重编译的原因。可以使用事件来获取这些信息。

SP: Recompile / SQL: StmtRecompile. The SP:Recompile and the SQL:StmtRecompile事件类显示哪些存储过程和语句曾经被重新编译过。当编译一个存储过程时，为存储过程和每一个被编译的语句生成事件。然而，当一个存储过程被重新编译时，只有引起重新编译的语句才会被生成一个事件（不同于SQL Server 2000中的整体存储过程编译）。