美创科技技术社区

注册

 

发新话题 回复该主题

Oracle性能测量体系(Parse Time) [复制链接]

1#

Oracle性能测量体系(Parse Time) 2013-11-04 22:10:24


分类: Oracle


  时间响应指标:
          RT:= CLient Time + Network TIme + DB Time
          DB Time:= Parse TIme + Execute Time + Commit TIme

         Parse Time:=Parse CPU Time + Parse Wait Time
        Parse Wait Time:= Parse Time – Parse CPU Time
        Parse Time:= Hard Parse Time + Soft Parse Time
        Hard Parse Time:= Hard Parse CPU + Hard Parse Wait Time

       吞吐量指标:
       Parse Count
       Hard Parse Count

       众所周知:Hard Parse的成本远远高于soft parse,而不同的soft parse其成本差异也极大。采用Parse Count作为Parse Time的吞吐量指标不是很准确,我们认为采用以下指标作为Parse 阶段的吞吐量指标会更加真实。
       parse过程基本上是不断访问shared pool的过程,由于我们无法从total LIO中分解出parse过程的LIO,我们采用访问内存必须的latch获得来进行parse吞吐量计数:
      
       library cache latch gets
       shared pool latch gets
      row cache objects latch gets

      采用mutex的度量会遇到问题,mutex仅仅记录具有sleep的mutex,在一个高吞吐量系统应该不存在着no sleep的mutex,这里暂且采用mutex sleep的进行合计。问题是awr自动收集缺乏mutex信息,使我们需要自己来收集mutex相关信息。
      从简单测试发现,v$mutex_sleep_history无法代表lmutex的get数量,所以采用这个来衡量吞吐量需要另外去获得。

    我们来看一下相关的比较:
      1431595225    parse time elapsed    79926695
       372226525    hard parse elapsed time    77738549

    3    549    parse count (total)    64    46471    
    4    550    parse count (hard)    64    2452    

    1    row cache objects    1253506
    2    shared pool              333468

    由于library cache latch为parse阶段最为重要的latch,在mutex模式似乎没有办法获得。如果无法获得mutex的get通道,也许采用latch或者mutex gets来标记parse级别吞吐量存在问题。

    为什么选择latch gets来替代parse count:

    latch gets可以精细的描述各种不同的parse,使不同的parse可以被同一个标准所衡量。

    比如我们来看:
       parse count无法标记出:soft parse,soft soft parse,no parse以及High Version parse之间的区别,大家知道即使是soft parse,soft soft parse等等会有各自很大的不同,但是latch gets在某种程度上可以准确的衡量出不同parse之间的成本差异。

分享 转发
TOP
发新话题 回复该主题