如何track存储过程的编译次数

简介: 原文: 如何track存储过程的编译次数 转载自此处 有个script我们很熟悉,是用来去查找当前SQL Server中哪些存储过程变重编译的次数最多的:   --Gives you the top 25 stored procedures that have been recompiled.
原文: 如何track存储过程的编译次数

转载自此处

有个script我们很熟悉,是用来去查找当前SQL Server中哪些存储过程变重编译的次数最多的:

 

--Gives you the top 25 stored procedures that have been recompiled.

 

select top 25 sql_text.text, sql_handle, plan_generation_num,  execution_count,

    dbid,  objectid

into DMV_Top25_Recompile_Commands

from sys.dm_exec_query_stats a

    cross apply sys.dm_exec_sql_text(sql_handle) as sql_text

where plan_generation_num >1

order by plan_generation_num desc

go

 

那么,这个脚本究竟是记录什么情况下的存储过程recomile呢?

 

我们在SQL Server上创建一个这样的store procedure

 

create proc aaa

as

select plan_generation_num,* FROM DMV_Top25_Recompile_Commands where plan_generation_num  > 2

 

然后准备好用这个脚本来返回plan_generation_num的值

select top 25 sql_text.text, sql_handle, plan_generation_num,  execution_count,

    dbid,  objectid

from sys.dm_exec_query_stats a

    cross apply sys.dm_exec_sql_text(sql_handle) as sql_text

where  sql_text.text like '%aaa%'

order by plan_generation_num desc

 

 

Exec aaa之后的脚本返回结果:

 

这里的第六行结果集就是我们的存储过程aaa。这时的plan_generation_num值显示为1.

 

接下来我们mark recompile

sp_recompile aaa

然后再次执行 exec aaa

 

使用脚本查询:

 

 

这里看到存储过程重编译以后,plan_generation_num的值并没有增加。

那为什么我们还会使用这样的脚本来返回重编译次数很多的存储过程呢?

 

接下来我们再次将存储过程mark recompile,然后直接使用脚本查询:

这时,我们发现该存储过程的plan text已经从DMV中移除了。看起来sp_recompile会直接将cache中缓存的执行计划和语句直接标识成不可用。因此DMV中就没有相关的记录了。

这就是说,存储过程标识重编译这种模式导致的重编译,从DMV里面是没有办法跟踪的。

 

那么从性能监视器的计数器 sp recompilation/sec”里面能不能跟踪到呢?

我们反复执行:

sp_recompile aaa

exec aaa

 

性能监视器中一直显示为0

 

那么plan_generation_num的值究竟是什么含义呢?BOL中的解释很简单:

A sequence number that can be used to distinguish between instances of plans after a recompile.

中文版的含义为:可用于在重新编译后区分不同计划实例的序列号。

 

这里并没有说明如何去计算的序列号。我们从另一篇英文的blog中找到了更加详细的说明:

There are a lot of interesting columns in P and S, especially in S, and here I will only discuss what I have learned about plan_generation_num in S. SQL Server 2005 treats the compiled plan for a stored procedure as an array of subplans, one for each query statement. If an individual subplan needs recompilation, it does so without causing the whole plan to recompile. In doing so, SQL Server increments the plan_generation_num on the subplan record to be 1 + MAX(plan_generation_num for all subplans). The general distribution of plan_generation_num among all subplans for a given plan is such that it has multiple of 1's and distinct numbers > 1. That is because all subplans start with 1 as their plan_generation_num. Appendix A is the query for learning plan_generation_num.

 

http://lfsean.blogspot.com/2008/02/understanding-sql-plangenerationnum.html

 

这部分说明简单的来说,就是只要存储过程中有一条语句发生重编译,这个plan_generation_num值就会+1.这里并没有说是整个存储过程重编译的时候,这个值会+1.

 

接下来我们修改测试存储过程aaa

 

Alter TABLE aaa_table(

[text] [nvarchar](max) NULL,

[sql_handle] [varbinary](64) NOT NULL,

[plan_generation_num] [bigint] NOT NULL,

[execution_count] [bigint] NOT NULL,

[dbid] [smallint] NULL,

[objectid] [int] NULL

) ON [PRIMARY]

 

insert into aaa_table select * from DMV_Top25_Recompile_Commands where 1=2

insert into aaa_table select * from DMV_Top25_Recompile_Commands where 1=2

insert into aaa_table select * from DMV_Top25_Recompile_Commands where 1=2

insert into aaa_table select * from DMV_Top25_Recompile_Commands where 1=2

insert into aaa_table select * from DMV_Top25_Recompile_Commands where 1=2

 

 

然后我们执行存储过程,收集profiler trace,同时继续监控性能监视器

开始重新执行存储过程aaa

 

这里我们可以看到sp recompilation/sec立刻变成了7

Profiler trace中可以看到每条insert语句上都触发了一个sp:recompile

 

 

脚本的查询结果:

 

可以看到plan_generation_num的值增加到6了。

 

为什么这样写存储过程会导致重编译?http://support.microsoft.com/kb/243586 这篇文章中列举了多种会导致存储过程重编译的情况:

aaa这个存储过程符合这个条件:

The procedure interleaves Data Definition Language (DDL) and Data Manipulation Language (DML) operations.

 

因此我们的结论是,使用这个脚本去查询重编译次数高的存储过程是没有错的,但是这个脚本并不包含由于sp_recompile已经定义存储过程时使用了with recompile的选项而导致的存储过程重编译的情况。


目录
相关文章
|
8月前
|
存储 Oracle 关系型数据库
Oracle中“ORA-00060: 等待资源时检测到死锁” 或存储过程编译卡死的一种解决方法
Oracle中“ORA-00060: 等待资源时检测到死锁” 或存储过程编译卡死的一种解决方法
597 0
|
SQL 存储 缓存
sqlserver 存储过程中使用临时表到底会不会导致重编译
原文:sqlserver 存储过程中使用临时表到底会不会导致重编译 曾经在网络上看到过一种说法,SqlServer的存储过程中使用临时表,会导致重编译,以至于执行计划无法重用,运行时候会导致重编译的这么一个说法,自己私底下去做测试的时候,根据profile的跟踪结果,存储过程中使用临时表,如果不是统...
978 0
|
存储 SQL 测试技术
SQL SERVER 临时表导致存储过程重编译(recompile)的一些探讨
原文:SQL SERVER 临时表导致存储过程重编译(recompile)的一些探讨     SQLSERVER为了确保返回正确的值,或者处于性能上的顾虑,有意不重用缓存在内存里的执行计划,而重新编译执行计划的这种行为,被称为重编译(recompile)。
870 0
|
存储 Oracle 关系型数据库
|
存储 Oracle 关系型数据库
|
SQL 存储 关系型数据库
oracle编译存储过程提示表或视图不存在的问题分析
       今天有同事跟我反映有个存储过程编译报错,提示表或视图不存在。存储过程中调用的那个表t是另一个用户b的表。
1470 0
|
存储 Oracle 关系型数据库
由于存储过程及触发器引用ORACLE动态视图v$session编译不通过而执行时报错ORA-04098
    今天遇见一个很神奇的问题,ERP合同系统需要记录登录oracle数据库的用户名、IP地址、登录时间、登录客户端类型记录信息,需要创建个触发器, 在触发器中需要查询v$session视图,如下所示:  create or replace trigger EPMFRAMEWORK.
1062 0
|
存储
编译存储过程 等待锁定对象 时超时问题解决
编译的存储过程的时候,程序死住,等待一会出现ora-04021错误解决办法:1.可能被锁住 查看v$lockedselect b.sid,b.serial#,b.machine,b.terminal,b.
1001 0