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/，如需轉載，請註明出處，否則將追究法律責任。