Trace回放功能及案例
简述:重播跟踪的用途
第一节:重播的使用要求及方法
第二节:重播应用案例
简述
重播-----是指重新执行跟踪到的Trace脚本。是一种低成本的分析方案,用作于分析特定的逻辑问题(如锁),性能调整比较,容量规划,压力测试等。可以根据分析的需要,在不同机器,多次,任意时间执行分析,而不影响生产库环境。
第一节 重播的使用要求
跟踪文件的要求
为了重放工作负荷文件,跟踪中必须包含特定的事件,如(CursorClose等),如果缺少必须的事件,回放时则会在SQL Profiler中看到如下错误信息。
图一
错误提示中有必须的事件列表。最简单的新建方法为,采用TSQL-Replay跟踪模版,可以满足重放的最低要求。
要重播的测试机配置要求
1:工作负荷中包含的所有登录(SQL和Windows)在测试机上要存在
2: 工作负荷中包含的DB在测试机上要存在
3: 用户权限,密码在测试库要与生产环境中相同
4: 每次重播后,对数据造成较大改动的,都要还原数据库后再进行下次重播的分析
5: 特别注意,重放跟踪不能连接到正式库重播,否则会造成测试数据进入到生产中
重播的方法
说明:
1:F5开始执行重播
2:单步,多行,设置断点执行
3:可以进行一些性能的对比
第二节 重播案例
这节主要分析四个应用场景
·场景1:分析因特定顺序原因产生的死锁
·场景2:性能调优后,重放用户行为,分析资源消耗的变化
·场景3:把多个Trace文件同时在同一台机器上重播,进行压力测试
·场景4: trace文件在不同配置的机器上重播,进行容量的规划(需测试机,不进行测试)
测试场景:
场景1:
在IT-001 (下称A)服务器上执行特定构造的死锁,跟踪后保存Trace文件。在IT-002(下称B) 重播跟踪,重现死锁,到B找到问题,修正,并重播正常后,再调整模拟生产库A问题。
测试步骤:
1:按要求配置A,B服务器,打开Profile重放模版跟踪A活动。
2:在A上用系统帐号,及sa帐号分别登录。
3:用两用户,分别执行构造的死锁代,如下:
(begin tran
update testReplay.dbo.Table1 Set B='BN2' where ID=2
waitfor delay '00:00:30'
Commit)
4:保存Trace文件,连接到B服务器重新播放
5:产生如下死锁,分析明确原因,调整至正常
(重现死锁图)
说明:该特性可以重现复杂调用产生的锁,用来分析调整问题
场景2:
在A上模拟一定数量登录,退出,SP运行各种操作,跟踪并保存trace文件,先在B上进行重播建立性能基线,再把B进行性能调优,重播分析原负荷文件消耗CPU,read,write,执行时间等变化。
测试步骤
1:将A上新建Test表,Create Table Test (ID,SName,SAge),并且随机产生120万SName字段的记录,并建立更新Test表记录的SP
2:打开Profile重放模版跟踪A活动。
3:在A上用系统帐号,及sa 帐号分别登录。
4:用两用户,分别循环执行TestReplay.dbo.Test_Replay_Update存储过程100次和200次
5:保存Trace文件,连接到B服务器进行重放(此时B上Test表无索引),登记执行时间,资源消耗的数据,
建立基线。(如图红框内为重播基线时间,共(368s))
6:对B的Test表Sname加上聚集索引,重新播放,
得到重播时间为23秒
7: 分析改善,由于本例子只有登录和执行SP两个操作消耗时间,登录耗时极短忽略,那么
(基线播放时间-本次重播耗时)/本次重播耗时,就是优化对象性能提升的比例。
提升(368-23/)23*100%=1500%左右
说明:1:本例可模仿多用户大量执行SP,查看系统CPU,IO等调优前后的变化.
2:若分析重播时CPU,IO变化,需另外开启Profile进行普通跟踪分析.(筛选条件要包含profile)
场景3:
同一Trace文件打开多个实例,同时在一台机器上重播,进行压力测试,并把trace与系统System Monitor图形数据进行关联。比较机器容纳压力。
测试步骤:
1:在重播机器B上建立Monitor性能计数器M1,并新建普通跟踪T1.
2:利用场景2建立的回放脚本,同时打开4个Profile客户端,连接到B上同时进行重播.
3:四个重播脚本运行完后,停止普通跟踪T1,重新打开T1后,再导入M1(普通性能计数器),
建立Trace与Monitor的关联.
图形如下
说明:
1: Trace文件与Monitor计数器是通过时间片关联,反映同一时刻资源使用情况.
2: 在B上同时运行多个Trace重播,可反映出B机器接受多大的压力,资源消耗的情况
------2009.10.20