AWR——Instance Efficiency Percentages (Target 100%)

目前都是AMM並ASMM記憶體管理，所以基於命中率的調優方法論已經過時(因為這是個平均值的概念，就像1和100的平均是50.5一樣不代表完全準確)，但仍具有參考價值，全部是越高越好！

Buffer Nowait %：session申請一個buffer(相容模式)在db buffer cache中不等待的次數比例。

 

Buffer Hit %：資料塊在資料緩衝區中的命中率，小於90%可能是要加db_cache_size，但這個指標即便99% 也不能說明物理讀等待少了，但是指標小於90%，那肯定是存在大量物理讀

 

Library Hit %：申請一個library cache object例如一個SQL cursor時，其已經在library cache中的比例（表示Oracle從Library Cache中檢索到一個解析過的SQL或PL/SQL語句的比率），低的library hit ratio會導致過多的解析，增加CPU消耗。比例過小則需要增加shared pool大小

 

Execute to Parse %：表示sql語句解析後被重複執行的命中率，如果該值偏小，說明分析（硬分析和軟分析）的比例較大，快速分析較少，其公式為 1-(parse/execute)

 

Parse CPU to Parse Elapsd %：解析CPU時間和總的解析時間的比值(Parse CPU Time/ Parse Elapsed Time)【解析實際執行時間/(解析實際執行時間+解析中等待資源時間)】；若該指標水平很低，那麼說明在整個解析過程中 實際在CPU上運算的時間是很短的，而主要的解析時間都耗費在各種其他非空閒的等待事件上了（有時候Parse CPU to Parse Elapsd%會超過100%，這是由於四捨五入造成的，CPU Time是一點一點紀錄，並累加的（按SQL Parse 中的每個Call）而Elapsed Time 是一段一段紀錄，並累加的（按SQL 一次parse）比如說，現在開始一個 parse , 中間有100次call, 本來每次應該是 0.8 微秒，但是，Oracle 紀錄時每次計成是 1 微秒，結果，這一次的parse CPU 被記錄成 100 微秒。而Elapsed Time 紀錄的是整個的時間，等於 0.8 *100 + （wait time）,結果就可能小於 100 微秒。而最終結果就是 Parse CPU to Parse Elapsd% > 100%）

 

Redo NoWait %：session獲取buffer 在redo buffer cache中不用等待的比例，redo相關的資源如redo space request爭用可能造成生成redo時需求等待。

 

In-memory Sort %：排序在記憶體PGA中的比例。（不是workarea中所有的操作型別只是排序，所以現在越來越雞肋了），比例過小則需要增加PGA_AGGREGATE_TARGET值

 

Soft Parse %：軟解析的百分比，softs/(softs+hards), 太低則需要調整應用使用繫結變數

 

Latch Hit %：閂申請不要等待的比例

 

% Non-Parse CPU：非解析cpu比例，公式為 (DB CPU – Parse CPU)/DB CPU， 若大多數CPU都用在解析上了，則可能好鋼沒用在刃上了。