none
为何使用RML Utilities Replay时,分析结果与最初的不一样? RRS feed

  • 问题

  • 版本:Sql Sevrer 2005

    初次使用RML Utilities(最新),步骤严格按照操作手册中Quik Start进行。Setup、Capture、Analyze都很顺利,Analyze成功导入Capture时生成.TRC,并生成.RML,同时Reporter自动跳出显示分析结果。

    但是到了Replay时,生成的.TRC文件大小远远小于之前的,且Reporter显示的分析结果也与之前不同。

    由于在Replay时,没有使用操作手册中提到的Replay Instance,而是在同一台服务器上进行,所以步骤有所不同,简单描述下:

    1、Drop Database PrecisionPerformance,将之前在Analyze是备份的PercisionPerformance.bak Restore;

    2、由于是同一台服务器,因此没有Review SQLDiag capture、sp_configure settings;

    3、执行sqldiag.exe /Oc:\temp\PPSecure /IPPConfig.xml以及执行TraceCaptureDef.sql;

    4、dbcc freeproccache与dbcc dropcleanbuffers;

    5、执行ostress -E -S(local) -ic:\temp\PPBreakout\*.rml -cc:\temp\sample.ini -oc:\temp\PPBreakout\Replay -mreplay -T88 -dPrecisionPerformance -T33。注,操作手册该语句原为-S(replay instance),但由于用了同一台服务器,因此我改成了-S(local);c:\temp\PPBreakout\下的*.rml由上一次Analyze时生成;

    6、Replay结束后,停止跟踪。

    究竟是什么原因造成了Replay时分析结果的不同?还请知道的高手解答,谢谢。

    2011年2月25日 2:45

全部回复

  • 网上关于RML的资料很少,手头仅有操作手册。

    或是能提供相关资料也ok。

    2011年2月25日 5:25
  • 检查reeplay 出错没有
    想不想时已是想,不如不想都不想。
    2011年2月25日 10:06
    版主
  • 我一般都是导入Capture时生成.TRC,并生成.RML,同时Reporter自动跳出显示分析结果。然后使用这个结果的,你为什么还要replay 呢
    2011年2月26日 1:41
  • 谢谢各位的答复。

    1、仔细看过Replay的提示,没有看到提出出错的字样;

    2、之所以要Replay,是为了比较在相同压力测试情况下数据库优化前后的性能,这也是RML一个非常不错的功能。在我认为,若数据库未作任何设置变动的情况下,Replay得出的结果应该和之前的相差不大。

    是不是对于sql server的性能分析,大家用的是其他工具,而非RML?

    2011年2月27日 11:29
  • 自己顶一下
    2011年3月1日 3:06
  • Hi JarrodChen,

     

    一般来说,为了能够从Trace文件中提取有用的信息,并用于Replay,Capture的Trace文件会包含更多的Columns以及部分不能参与Replay的Events,Replay时生成的Trace文件不会包含这些,所以会小一些。

     

    关于Replay的结果和Capture的不同,这个和很多因素有关,而且大多数的Replay工具也无法保证完全这点。如果想提高相似度或一致性,可以从以下几方面尝试:

    1. Replay Mode的选择,RML支持两种Replay Mode,一种是Sequential,会尽量保证按照Capture时的命令顺序来Replay,由于需要由ORCA来统一协调不同机器/线程的提交顺序,保证了顺序,保证不了Replay的速度。另一种是Delta,这种方式只保证在同一个Spid内的命令顺序与Capture时是一致的,不保证Spids之间的命令顺序,大多数情况下这种方式的Replay会相对上一种快。

    2. Trace有多少并发Spids,replay的时候,OSTRESS基本上会为每一个Spid创建一个线程,可根据Captured Trace的具体情况考虑用几个机器来Replay(对于Sequential方式的Replay,多个机器有可能会变慢,因为ORCA需要协调多个机器上的线程,比协调同一个机器内的线程费时)。

    3. 观察Replay的瓶颈在哪里,可以查看Replay机器上的CPU、Memory,Disk以及Network的使用情况(perfmon中有相关的Counters),同时查看DB机器上的相关信息以及BatchRequest / Sec,通过调整硬件或replay的参数来缓解瓶颈部分的压力,一般来说Network不是问题。

    4. 查看Replay的Pass Rate是否正常,如果由于Replay环境搭建有问题(如权限),会导致Replay变慢或变快。

     

    仅供参考,希望能有所帮助。

     


    Thanks, Elton
    2011年5月24日 7:44