關於AWR報告中幾個命中率指標的初步解釋

it_newbalance發表於2013-05-29
      從Oracle 10g開始,Oracle給廣大DBA提供了一個效能優化的利器,那便是Automatic Workload Repository效能報告。

在拿到一份AWR效能報告後,通過分析AWR報告來定位資料庫效能問題時,在AWR報告的報告頭中,我們會看到類似如下的一些命中率指標:

Instance Efficiency Percentages [Target 100%]

Buffer Nowait %:99.87Redo NoWait %:99.95
Buffer Hit %:95.89In-memory Sort %:100.00
Library Hit %:86.87Soft Parse %:99.26
Execute to Parse %:91.37Latch Hit %:99.73
Parse CPU to Parse Elapsd %:53.78% Non-Parse CPU:98.18

那麼,這些關於Oracle記憶體的幾個關鍵指標以及Instance效率的幾個指標又該如何理解呢?

1 這幾個指標重要,但是通過這些命中率指標並非就可以定位到問題的關鍵所在。如上,我們看到各項指標基本都很高,除Parse CPU to Parse Elapsd %:只有53.78%之外,但是,該統計資料是來自於一則生產環境下出現嚴重效能問題的一個小時取樣資料。

2 分別對上述表格中各項指標作一初步解釋:

Buffer Nowait %:表示會話向Database Buffer Cache【資料高速緩衝區】 申請1個快取時不等待的比例;

Buffer Hit %:表示資料高速緩衝區的命中率,也叫Cache Hit Ratio。該指標要分實際業務系統型別來分析,如OLAP系統,該值可能為20%就算合理,而對於OLTP系統來講,理想值應該在90%以上。當然,並非該值達到100%就沒問題了,系統中可能依然難以避免物理讀等待。計算指令碼:

1SELECT (1 - (phys.value / (db.value + cons.value))) * 100 AS "Buffer Cache Hit Ratio"
2FROM v$sysstat phys,
3 v$sysstat db,
4 v$sysstat cons
5WHERE phys.name = 'physical reads'
6AND db.name = 'db block gets'
7AND cons.name = 'consistent gets';

Library Hit %:Library Cache Hit Ration【庫高速緩衝區命中率】,表示向共享池的Library Cache中申請1個Library Cache Object物件時,其已經在Library Cache中存在的比例。該指標的一個合理值應該達到95%以上。計算指令碼:

1SELECT (1 -(Sum(reloads)/(Sum(pins) + Sum(reloads)))) * 100 AS "Library Cache Hit Ratio"
2FROM v$librarycache;

Execute to Parse %:表示執行解析比,目標是希望一次解析多次執行,計算公式=[1-(parse count (total)/(execute count)]%=[1-1257816/14576118]%=91.37%,其中parse count (total)來源於V$SYSSTAT中的parse count (total)欄位值,execute count則取值於execute count的欄位值。同時在同一份AWR報告中,parse count (total)execute count的值可以從AWR報告的Instance Activity Stats章節中獲取,如下摘錄

Instance Activity Stats

  • Ordered by statistic name
StatisticTotalper Secondper Trans
Batched IO (bound) vector count560,211157.6928.15
CPU used by this session1,434,831403.8872.10
。。。。。。。。。。。。。。
execute count14,576,1184,102.96732.43
。。。。。。。。。。。。。。
parse count (describe)90.000.00
parse count (failures)280.010.00
parse count (hard)9,3642.640.47
parse count (total)1,257,816354.0663.20
parse time cpu26,7237.521.34
parse time elapsed49,68713.992.50
redo entries7,072,4851,990.80355.38
redo log space requests3,6651.030.18
。。。。。。。。。。。。。。
sorts (disk)70.000.00
sorts (memory)22,108,3256,223.161,110.92
。。。。。。。。。。。。。。
。。。。。。。。。。。。。。
write clones created in foreground2,2430.630.11

Parse CPU to Parse Elapsd %:該指標表示解析消耗的CPU時間與解析消耗的總時間的比值,目標同樣是100%。我們當然希望解析的過程中,時間都消耗在CPU上,而不希望在解析的過程中,出現其他等待事件而拉長解析消耗的總時間。如果該指標偏低的話,說明在解析的過程中,除了消耗CPU資源外,還有其它等待事件,如等待共享池物件、閂鎖。計算公式=[parse time cpu/parse time elapsed]%,parse time cpu和parse time elapsed同樣來自於V$SYSSTAT,也可以參照AWR報告中Instance Activity Stats章節中的資料,如:Parse CPU to Parse Elapsd %:=[26723/49687]%=53.78%。

Redo NoWait %:表示會話寫Redo Entry時不等待的比例。計算公式=[1-redo log space requests/redo entries]%,同樣該兩項指標來自於V$SYSSTAT字典表,也可以參照AWR報告中Instance Activity Stats章節中的資料,如Redo NoWait %:=[1-3665/7072485]%=[1-0.0005]%=99.95%。

In-memory Sort %:表示在記憶體中排序的比例。計算公式=[1-sorts (disk)/sorts (memory)]%,同樣該兩項指標來自於V$SYSSTAT字典表,也可以參照AWR報告中Instance Activity Stats章節中的資料,如In-memory Sort %:=[1-7/22108325]%=99.9999%。

Soft Parse %:表示軟解析比例。計算公式=【1-parse count (hard)/parse count (total)】,同樣該兩項指標來自於V$SYSSTAT字典表,也可以參照AWR報告中Instance Activity Stats章節中的資料,如Soft Parse %:=[1-9364/1257816]%=99.26%。

Latch Hit %:表示以 willing-to-wait 方式去獲取記憶體栓鎖的命中率指標,通常這個指標要求至少在99%以上,否則,很有可能意味著大量栓鎖等待,影響效能。該值來源於V$LATCH字典表中的GETS和MISSES欄位值計算指令碼:

1SELECT (1 - (Sum(misses) / Sum(gets))) * 100 AS "Latch Hit Ratio"
2FROM v$latch;

% Non-Parse CPU:表示除解析之外CPU的使用率,計算公式=【1-(parse time cpu)/(CPU used by this session)】%。同樣該兩項指標來自於V$SYSSTAT字典表,也可以參照AWR報告中Instance Activity Stats章節中的資料,如% Non-Parse CPU:=[1-26723/1434831]%=98.18%。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/24558279/viewspace-762371/,如需轉載,請註明出處,否則將追究法律責任。

相關文章