Oracle性能测量体系（Parse Time)

  时间响应指标：
      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之间的成本差异。


 
  




  

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/92650/viewspace-775662/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/92650/viewspace-775662/