AWR报告阅读提要

AWR（Automatic Workload Repository，自动工作负荷知识库）是oracle 10g开始推出的特性，它通过对比两次快照（snapshot）收集的统计信息，生成有关实例和数据库性能及健康状况的统计报表。

选择报表时间段很关键，要选择能够代表性能问题的时间段。如果快照周期不在这一段时间内，或者快照周期跨度太长而包含了大量的空闲时间，所得出的分析结果是没有意义的。

以下是一个来自实际生产系统的AWR报告，下面以此例做个简要介绍。

报头

这里包含了主机实例和数据库的最基本信息。报告包含快照的前后时间、会话数、数据库运行总体时间消耗。主要看点就是对比时间消耗：

DB Time：非系统后台进程所消耗的数据库时间，即所有会话连接给数据库带来的时间消耗。即DB Time = CPU Time + Wait Time（不包含空闲等待）（非后台进程）。

Elapsed：数据库运行时间。

如果DB Time远小于Elapsed，说明数据库比较空闲，反之说明数据库比较忙碌，压力较大。

报告概要

这里显示了数据库各主要指标的统计信息，反映了数据库的总体运行情况。

Cache Sizes

该部分说明了实例主要几个内存块的大小。

Buffer Cache：SGA中数据库高速缓冲区缓存大小。

Shared Pool Size：SGA中共享池大小，包括库缓存、数据字典缓存等。

Std Block Size：标准数据块的大小。

Log Buffer：SGA中日志缓冲区大小。

Load Profile

该部分说明数据库的负载概况，如果每秒或每事务的负载变化不大，说明应用运行比较稳定。单个的数据只说明应用的负载情况，大多数据并没有一个所谓正确的值，应该通过对比来看其变化。

Redo size：每秒/每事务产生的日志大小（单位字节），反映数据变更频率， 数据库任务的繁重与否。

Logical reads：每秒/每事务产生的逻辑读的块数，Logical Reads= Consistent Gets + DB Block Gets。

Block changes：每秒/每事务修改的块数。

Physical reads：每秒/每事务物理读的块数。

Physical writes：每秒/每事务物理写的块数。

User calls：每秒/每事务用户调用次数。

Parses：每秒/每事务sql语句解析次数，包括硬解析和软解析。软解析每秒超过300次意味着应用程序效率不高，硬解析则是指SQL语句未在内存中命中。

Hard parses：硬解析的次数，硬解析太多，说明SQL重用率不高。每秒硬解析次数超过100，说明绑定变量使用的不好，也可能是共享池设置不合理。

Sorts：每秒/每事务的排序次数。

LoGons：每秒/每事务登录的次数，如果会话登录大于每秒1~2个，表明可能有争用问题。

Executes：每秒/每事务SQL执行次数。

Transactions：每秒产生的事务数，反映数据库任务繁重与否。

Blocks changed per Read：每次逻辑读中更改的数据块的百分比。

Recursive Call：递归调用所占比率，如果有很多PL/SQL，那么这个值就会比较高。

Rollback per transaction：每事务的回滚率，如果回滚率过高，说明数据库经历了过多的无效操作，过多的回滚可能会带来Undo块的竞争 。

Rows per Sort：平均每次排序的行数。

Instance Efficiency Percentages

该部分包含了Oracle关键指标的内存命中率及其它数据库实例操作的效率，目标是100%。同Load Profile一节，这一节也没有所谓正确的值，而只能根据应用的特点判断是否合适。

Buffer Nowait：表示在缓存中获得数据的未等待比例。该值一般需要大于99%。否则可能存在争用，可以在后面的等待事件中进一步确认。 

Buffer Hit：表示进程在数据块缓存中的读块命中率，监视这个值是否发生重大变化比这个值本身更重要。数据块在数据缓冲区中的命中率通常应在95%以上。否则可能需要调整内存分配参数，增加内存等。一个高的命中率，不一定代表这个系统的性能是最优的，频繁的访问可能会造成命中率很高的假相，

但是一个比较低的命中率，一般就会对系统的性能产生影响，需要调整。命中率的突变，往往是一个不好的信息。如果命中率突然增大，可以检查导致大量逻辑读的语句，如果命中率突然减小，可以检查产生大量物理读的语句，主要是那些没有使用索引的语句。

Llibrary Hit：表示Oracle从库缓存中检索到解析过的SQL或PL/SQL语句的比率，当应用程序调用SQL或存储过程时，Oracle检查库缓存确定是否存在解析过的版本，如果存在，Oracle立即执行语句，如果不存在，Oracle解析此语句，并在库缓存中为它分配共享SQL区。该值低表明存在过多的解析，增加CPU消耗，降低性能。如果低于90%，可能需要调大共享池、考虑使用绑定变量等。

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

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

Redo NoWait：表示在日志缓冲区中获得buffer的未等待比例。如果太低（参考90%阀值），考虑增加日志缓冲区大小，一般当redo buffer设置超过1M，不太可能存在等待buffer空间分配的情况。 

In-memory Sort：在内存中排序的比例，如果过低（参考95%阀值），说明有较多排序需要在临时表空间中进行，这样就会影响系统性能。

Soft Parse：软解析的比例，可近似当作SQL在共享池的命中率，太低则需要调整使用绑定变量。SQL在共享池中的命中率小于<95%，需要考虑绑定，低于80%，就可以认为SQL基本没有被重用。

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

要确保Latch Hit>99%，否则意味着存在Latch争用，可能由于未共享的SQL，或者库缓存太小，可使用绑定变更或调大共享池解决。可借助后面的等待事件和Latch分析来查找问题。

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

Shared Pool Statistics

该部分是共享池使用的统计信息。

Memory Usage：共享池内存使用率。对于一个已经运行了一段时间的数据库，该值应该在75%-90%，如果太小，说明共享池有浪费，如果高于90%，说明共享池有争用，内存不足。共享池设置过大会带来额外管理上的负担，从而影响系统性能。共享池过小会使组件过快老化，如果SQL语句再次执行，将使SQL语句被硬解析。

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

Memory for SQL w/exec>1：执行次数大于1的SQL消耗内存的占比，与不频繁使用的SQL语句相比，频繁使用的SQL语句消耗内存多少的一个度量。

Top 5 Timed Events 

这是报告概要的最后一节，显示了系统中最严重的5个等待事件，按等待时间的比例倒序排列。应从这里入手，考虑下一步做什么。例如该报告显示db file scattered read是最主要的等待，等待占比达到50%以上，说明存在大量的全表扫描未走索引的情况。通常在没有问题的系统中，CPU time应该列在第一个，否则说明系统大部分时间都用在等待上了。

主要问题看点

Wait Events Statistics

等待事件统计能快速反映影响系统运行性能的主要等待。这里主要看Wait Events一节的统计。

该表按照等待的时间排名，最影响性能的等待事件位于前列。以下就常见的一些等待事件做一说明。

db file scattered read：数据文件分散读。该等待事件典型地发生在全表扫描或全索引扫描上，反映了在读取一组连续的数据块时发生的I/O等待。如果该事件位于前列，说明可能有大量未走索引的SQL执行耗费了数据库时间，此时可以结合后面的SQL Statistics的统计信息查找未走索引而全表扫描的SQL语句。

db file sequential read：数据文件顺序读。该事件典型地发生在索引查找或通过rowid访问记录上，反映了在读取单个数据块上的I/O等待。该值过高通常是由于表间连接顺序不好，索引使用不当导致。

db file parallel write：缓存中的数据块被DBWR进程并行地写至磁盘时发生的I/O等待。该值高可能需要改善磁盘I/O性能。

log file parallel write：从日志缓冲区 写日志记录到联机日志文件时发生。如果存在多个日志组成员，则写操作是并行的，此时该等待事件可能出现。如果磁盘支持异步IO或者使用IO SLAVE，那么即使只有一个日志组成员，也有可能出现此等待。改善这个等待的方法是将联机日志文件放到I/O快的磁盘中，尽量不使用RAID5阵列，确保表空间不是处在热备模式下，确保日志文件和数据文件位于不同的磁盘上。

log file sync：等待LGWR进程将日志缓冲区的内容写至磁盘时发生。此事件发生在用户执行commit命令的时候。当用户提交数据时，LGWR需要将会话的日志记录从日志缓冲区填充到日志文件中，用户的进程必须等待这个填充工作完成。如果这个等待事件影响到数据库性能，那么就需要考虑修改应用程序的提交频率，一次提交更多的记录，或者将重做日志文件放在不同的物理磁盘上，避免使用RAID5阵列存储联机日志文件，提高磁盘I/O性能。

log buffer space：进程正在等待日志缓冲区的可用空间。典型地，该事件表明应用程序产生日志的速度超过了LGWR进程写日志到磁盘上的速度。该事件较高时，因分析产生大量日志的原因，增大日志缓冲区，改善磁盘I/O性能。

control file parallel write / control file single write / control file sequential read：当服务器进程更新或读取控制文件时发生该事件。如果等待很短，可以不用考虑。如果等待时间较长，应检查存放控制文件的物理磁盘I/O 是否存在瓶颈。多个控制文件是完全相同的拷贝，用于镜像以提高安全性，因此应该存放在不同的磁盘上。在同一个磁盘上保存多个控制文件并不具备实际意义。减少这个等待，可以考虑在确保安全的前提下减少控制文件的个数，使用异步磁盘I/O，转移控制文件到I/O负担较轻的磁盘上。

enqueue：由于锁机制而产生的队列等待。典型地，如用户试图修改表中的一行数据，而此行数据正被其他用户修改。

lach free：一个进程正在等待另一个进程持有的锁存器释放时发生该类等待事件。latch是一种能快速地被获取和释放的内存锁，用于保护SGA中的共享内存结构，防止被多个用户同时访问。SQL语句没有使用绑定变量、缓冲区存储竞争、缓冲区存在热点块等诸多原因都可能会出现该事件。

direct path read / direct path write：进程不经过数据库高速缓冲区缓存而直接读写磁盘数据块时发生的I/O等待。典型地，排序操作、并行DML操作、直接路径加载时发生该类等待。找到I/O 操作最为频繁的数据文件，如果有过多的排序操作，很可能就是临时文件，分散其负载，改善I/O性能。

SQL*Net message from client：表明用户会话的服务器进程已经完成一个用户请求，正在等待用户的下一个请求时发生的等待事件。

SQL Statistics

SQL统计查看影响系统运行性能的、比较耗时的SQL。这里优先看SQL ordered by Elapsed Time，按照执行SQL语句消耗的时间进行了排序。

如这里可以看出OPU条码打印程序执行的一段SQL消耗了大量的数据库时间，远远高于其他语句。点击SQL Id，页面跳转到该问题语句：

这是根据SN对WIP_TRACKING表执行的全字段查询。结合前面对等待事件的分析，由于同时存在大量的db file scattered read等待事件，因此估计该语句可能没有走索引，执行了全表扫描，导致严重的性能问题。将该语句单独拿出来看其执行计划，可以验证确实存在不走索引的情况，执行时间超过几秒以上。另外可以看到该查询虽然执行次数较多（Executions），但没有使用绑定变量，会导致频繁的硬解析。找到产生该问题语句的源头，结果我们发现它来自于OPU条码打印程序包里的config.xml文件，执行该语句的目的是随线打印时判断上一张条码是否已上线，前一个SN上线后才允许吐下一张条码。从业务功能上可以看出，完全没有必要做select *的操作，使用select 1 from rmes.r_wip_tracking_t where sn = ‘…’将会是更好的方法。

从这里还可以看到其它一些影响的语句，BoschPDC_SQLPUSH_ICON_MysqlPush_V3来自于BOSCH程序，w3wp来自于WEB程序，也可以看到FlexSite执行的主要耗时的存储过程和语句。

其它几种SQL统计简述如下：

SQL ordered by CPU Time：通过SQL语句在CPU运行时间上的消耗来排序，不包含执行SQL语句过程中的各类等待时间。

SQL ordered by Gets：通过SQL语句执行了多少逻辑读来排序。可以对比该条语句的Buffer Gets和后面统计的physical reads，如果两个比较接近，说明该语句存在问题。另外，我们在这里也可以关注gets per exec的值，这个值如果太大，表明这条语句可能使用了一个比较差的索引或者使用了不当的表连接。

SQL ordered by Reads：通过SQL语句执行了多少物理读来排序。这显示引起大部分物理I/O的SQL，当我们的系统存在I/O瓶颈时，需要关注这里I/O操作比较多的语句。效率低下的SQL往往伴随着大量的物理读，从而也造成了大量的数据块分散读等待。

SQL ordered by Executions：这里告诉我们这段时间中执行次数最多的SQL语句。可以考虑是否有必要更改逻辑，避免太过次数的查询。即使运行的很快，但被大量重复的操作都可能会消耗较多的数据库时间。

SQL ordered by Parse Calls：这里主要显示解析（Parse）与执行（Executions）的对比情况。如果Parse / Executions > 1，往往说明这个语句存在问题，如没有使用绑定变量，另外可能共享池设置太小等。

SQL ordered by Sharable Memory：这里主要是针对共享池的占用情况进行排序。

SQL ordered by Version Count：这里主要是针对SQL语句存在的多版本进行排序。相同的SQL文本，但属性可能不同，如对象的拥有者不同、会话优化模式不同、类型不同、长度不同、绑定变量不同等的SQL语句是不能共享的，所以在缓存中会存在多个不同的版本，当然也就造成了资源上的更多消耗。