我们知道使用RML工具分析跟踪数据(.TRC),其中的"Unique Batches",就是一个关于Batch级别的报表,Batch级别的报表针对的是存储过程或是一个TSQL Batch,存储过程或Batch内部的TSQL语句不会单独列在该报表上。很多存储过程调用或TSQL Batch语句总体是一样的,只是带的参数会有不同,ReadTrace会把这些仅是参数不同的存储过程或语句归为一类。
下图是筛选条件CPU>=30ms的跟踪文件,使用RML工具处理后,Top Unique Batches部分语句(这里使用报表语句在查询窗口得出,结果按NormText排序)
可以看到**HISTORY_111_0存储过程没有完全合并到一起,这和存储过程执行所带参数个数及参数顺序有关。
我们把前两条的NormText复制出来,光标移动到语句的末尾:
它们所带的参数个数不同,查证此存储过程定义了很多参数,部分带有默认值。
下面测试下存储过程执行所带参数个数与参数顺序,是否会影响到Unique Batches的分类。首先打开跟踪,用于收集存储过程的执行,在查询窗口运行下面语句:
use TestDB go create proc CheckUnique @parm1 int, @parm2 int=2, @parm3 int=3 as begin select @parm1,@parm2,@parm3 end go --传入一个参数 exec CheckUnique @parm1=1 exec CheckUnique @parm1=11 --传入两个参数 exec CheckUnique @parm1=1,@parm2=2 exec CheckUnique @parm1=1,@parm2=22 --调换参数顺序 exec CheckUnique @parm2=2,@parm1=1 --传入三个参数 exec CheckUnique @parm1=1,@parm2=2,@parm3=3
此时在Profiler客户端看到:
另存为跟踪文件到CheckUnique.trc,使用RML分析:
ReadTrace -I"F:TroubleShootingTraceCheckUnique.trc" -o"F:TroubleShootingTraceoutput" -S"127.0.0.1,7777" -d"PerfAnalysis_CheckUnique" -E
处理完成后,点击报表上的"Unique Batches",就可以得到一个关于语句级别的报表:
@parm1归为一类,@parm1,@parm2归为一类,@parm2,@parm1归为一类,@parm1,@parm2,@parm3归为一类。可见参数个数和参数顺序都会影响语句的归类。
那如果是普通的查询语句会是怎样呢?
--where条件不同 select * from sys.tables select * from sys.tables where type='U' select * from sys.tables where type='P' select * from sys.tables where type='U' and schema_id=5 select * from sys.tables where type='P' and schema_id=1 select * from sys.tables where schema_id=5 and type='U' --select字段不同 select name,create_date from sys.tables select create_date,name from sys.tables select name,object_id,create_date from sys.tables
Profiler客户端看到:
RML处理结果:
对比原始语句和处理后的语句,很容易知道RML同一类型的归类受以下条件影响:
对于存储过程,与传入参数个数及参数顺序有关
对于普通的SELECT,与返回字段、顺序及WHERE条件的字段、顺序都有关(UPDTAE、DELETE类似)