概述

AWR 是 Oracle 10g 版本 推出的新特性， 全称叫Automatic Workload Repository-自动负载信息库 AWR 是通过对比两次快照(snapshot)收集到的统计信息，来生成报表数据，生成的报表包括多个部分。

前面已经对awr报告的WORKLOAD REPOSITORY report部分做了介绍，下面根据生产环境对Report Summary部分的一些关键参数做分析，内容比较多，大家尽量耐心看完，还是有点用的。

cache sizes--内存参数大小

这里主要显示SGA中每个区域的大小（在AMM改变它们之后），可用来与初始参数值比较。

Buffer Cache：最终目的就是尽可能的减少磁盘I/O以便快速的读或写。也不是越大越好，如果Buffer Cache过大，会造成大的LRU 列表和 dirty list，引发逻辑读的过程消耗CPU量高。同时大的Buffer Cache也会增加DBWn 进程的负担。

shared pool主要包括library cache和dictionary cache。

library cache用来存储最近解析（或编译）后SQL、PL/SQL和Java classes等。
dictionary cache用来存储最近引用的数据字典。

发生在library cache或dictionary cache的cache miss代价要比发生在buffer cache的代价高得多。因此shared pool的设置要确保最近使用的数据都能被cache。

我们可以看到shared pool一直收缩，在shrink过程中一些row cache 对象被lock住可能导致前台row cache lock等解析等待，最好别让shared pool shrink。如果这里shared pool一直在grow，那说明shared pool原有大小不足以满足需求(可能是大量硬解析)，结合后面的解析信息和SGA breakdown来一起诊断问题。

Load Profile

这里可以看到生产的硬解析每秒为102，硬解析为7.5，问题不大，但是Logons每秒3.3，表明可能有争用问题，下面针对每个指标具体分析：

这里主要显示数据库负载概况，将之与基线数据比较才具有更多的意义，如果每秒或每事务的负载变化不大，说明应用运行比较稳定。

单个的报告数据只说明应用的负载情况，绝大多数据并没有一个所谓“正确”的值，Logons大于每秒1~2个、Hard parses大于每秒100、全部parses超过每秒300表明可能有争用问题。

Instance Efficiency Percentages (Target 100%)

上述所有指标 的目标均为100%，即越大越好，在少数bug情况下可能超过100%或者为负值。

80%以上 %Non-Parse CPU

90%以上 Buffer Hit%, In-memory Sort%, Soft Parse%

95%以上 Library Hit%, Redo Nowait%, Buffer Nowait%

98%以上 Latch Hit%

这里主要显示Oracle关键指标的内存命中率及其它数据库实例操作的效率。其中Buffer Hit Ratio 也称Cache Hit Ratio，

Library Hit ratio也称Library Cache Hit ratio。

在一个使用直接读执行大型并行查询的DSS环境，20%的Buffer Hit Ratio是可以接受的，而这个值对于一个OLTP系统是完全不能接受的。

根据多年的经验，对于OLTP系统，Buffer Hit Ratio理想应该在90%以上。

Buffer Nowait表示在内存获得数据的未等待比例。在缓冲区中获取Buffer的未等待比率

Buffer Nowait的这个值一般需要大于99%。否则可能存在争用

buffer hit 高速缓存命中率，反应物理读和缓存命中间的纠结，表示进程从内存中找到数据块的比率，监视这个值是否发生重大变化比这个值本身更重要

Redo NoWait表示在LOG缓冲区获得BUFFER的未等待比例。如果太低（可参考90%阀值），考虑增加LOG BUFFER。

当redo buffer达到1M时，就需要写到redo log文件，所以一般当redo buffer设置超过1M，不太可能存在等待buffer空间分配的情况。

library hit表示Oracle从Library Cache中检索到一个解析过的SQL或PL/SQL语句的比率，当应用程序调用SQL或存储过程时，

Oracle检查Library Cache确定是否存在解析过的版本，如果存在，Oracle立即执行语句；如果不存在，Oracle解析此语句，并在Library Cache中为它分配共享SQL区。

Latch Hit：Latch是一种保护内存结构的锁，可以认为是SERVER进程获取访问内存数据结构的许可。

要确保Latch Hit>99%，否则意味着Shared Pool latch争用，可能由于未共享的SQL，或者Library Cache太小，可使用绑定变更或调大Shared Pool解决。

要确保>99%，否则存在严重的性能问题。

Parse CPU to Parse Elapsd：解析实际运行时间/(解析实际运行时间+解析中等待资源时间)，越高越好。即：解析实际运行时间/(解析实际运行时间+解析中等待资源时间)。如果该比率为100%，意味着CPU等待时间为0，没有任何等待。

Non-Parse CPU ：SQL实际运行时间/(SQL实际运行时间+SQL解析时间)，太低表示解析消耗时间过多。

计算公式为：% Non-Parse CPU =round(100*1-PARSE_CPU/TOT_CPU),2)。如果这个值比较小，表示解析消耗的CPU时间过多。

Soft Parse：软解析的百分比（softs/softs+hards），近似当作sql在共享区的命中率

In-memory Sort：在内存中排序的比率，如果过低说明有大量的排序在临时表空间中进行。

Execute to Parse：是语句执行与分析的比例，如果要SQL重用率高，则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。

Shared Pool Statistics

Memory Usage %：对于一个已经运行一段时间的数据库来说，共享池内存使用率，应该稳定在75%-90%间，

如果太小，说明Shared Pool有浪费，而如果高于90，说明共享池中有争用，内存不足。

这个数字应该长时间稳定在75%～90%。如果这个百分比太低，表明共享池设置过大，带来额外的管理上的负担，从而在某些条件下会导致性能的下降。如果这个百分率太高，会使共享池外部的组件老化，如果SQL语句被再次执行，这将使得SQL语句被硬解析。这里显示生产环境比率低于75%，没有充分利用shared pool。

SQL with executions>1：执行次数大于1的sql比率，如果此值太小，说明需要在应用中更多使用绑定变量，避免过多SQL解析。

在一个趋向于循环运行的系统中，必须认真考虑这个数字。在这个循环系统中，在一天中相对于另一部分时间的部分时间里执行了一组不同的SQL语句。

在共享池中，在观察期间将有一组未被执行过的SQL语句，这仅仅是因为要执行它们的语句在观察期间没有运行。只有系统连续运行相同的SQL语句组，这个数字才会接近100%。

Memory for SQL w/exec>1：执行次数大于1的SQL消耗内存的占比。

这是与不频繁使用的SQL语句相比，频繁使用的SQL语句消耗内存多少的一个度量。

这个数字将在总体上与% SQL with executions>1非常接近，除非有某些查询任务消耗的内存没有规律。

在稳定状态下，总体上会看见随着时间的推移大约有75%～85%的共享池被使用。如果Statspack报表的时间窗口足够大到覆盖所有的周期，

执行次数大于一次的SQL语句的百分率应该接近于100%。这是一个受观察之间持续时间影响的统计数字。可以期望它随观察之间的时间长度增大而增大。

总结：通过ORACLE的实例有效性统计数据，我们可以获得大概的一个整体印象，但是不能由此来确定数据运行的性能。当前性能问题的确定，我们主要还是依靠后面介绍的等待事件来确认。

可以这样理解两部分的内容，hit统计帮助我们发现和预测一些系统将要产生的性能问题，这样可以做到未雨绸缪。而wait事件，就是表明当前数据库已经出现了性能问题需要解决，所以是亡羊补牢的性质。

后面会分享更多DBA方面的内容，感兴趣的朋友可以关注下！！