时间响应指标：

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/，如需转载，请注明出处，否则将追究法律责任。