从Oracle 10g开始，Oracle给广大DBA提供了一个性能优化的利器，那便是Automatic Workload Repository性能报告。
在拿到一份AWR性能报告后，通过分析AWR报告来定位数据库性能问题时，在AWR报告的报告头中，我们会看到类似如下的一些命中率指标：
Instance Efficiency Percentages [Target 100%]
| Buffer Nowait %: | 99.87 | Redo NoWait %: | 99.95 |
| Buffer Hit %: | 95.89 | In-memory Sort %: | 100.00 |
| Library Hit %: | 86.87 | Soft Parse %: | 99.26 |
| Execute to Parse %: | 91.37 | Latch 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%就没问题了，系统中可能依然难以避免物理读等待。计算脚本：
SELECT (1 - (phys.value / (db.value + cons.value))) * 100 AS "Buffer Cache Hit Ratio"
FROM v$sysstat phys,
v$sysstat db,
v$sysstat cons
WHERE phys.name = 'physical reads'
AND db.name = 'db block gets'
AND cons.name = 'consistent gets';
③ Library Hit %:Library Cache Hit Ration【库高速缓冲区命中率】，表示向共享池的Library Cache中申请1个Library Cache Object对象时，其已经在Library Cache中存在的比例。该指标的一个合理值应该达到95%以上。计算脚本：
SELECT (1 -(Sum(reloads)/(Sum(pins) + Sum(reloads)))) * 100 AS "Library Cache Hit Ratio" FROM 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
| Statistic | Total | per Second | per Trans |
|---|---|---|---|
| Batched IO (bound) vector count | 560,211 | 157.69 | 28.15 |
| CPU used by this session | 1,434,831 | 403.88 | 72.10 |
| 。。。。。 | 。。。 | 。。。 | 。。。 |
| execute count | 14,576,118 | 4,102.96 | 732.43 |
| 。。。。。 | 。。。 | 。。。 | 。。。 |
| parse count (describe) | 9 | 0.00 | 0.00 |
| parse count (failures) | 28 | 0.01 | 0.00 |
| parse count (hard) | 9,364 | 2.64 | 0.47 |
| parse count (total) | 1,257,816 | 354.06 | 63.20 |
| parse time cpu | 26,723 | 7.52 | 1.34 |
| parse time elapsed | 49,687 | 13.99 | 2.50 |
| redo entries | 7,072,485 | 1,990.80 | 355.38 |
| redo log space requests | 3,665 | 1.03 | 0.18 |
| 。。。。。 | 。。。 | 。。。 | 。。。 |
| sorts (disk) | 7 | 0.00 | 0.00 |
| sorts (memory) | 22,108,325 | 6,223.16 | 1,110.92 |
| 。。。。。 | 。。。 | 。。。 | 。。。 |
| 。。。。。 | 。。。 | 。。。 | 。。。 |
| write clones created in foreground | 2,243 | 0.63 | 0.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字段值计算脚本：
SELECT (1 - (Sum(misses) / Sum(gets))) * 100 AS "Latch Hit Ratio" FROM 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%。