如何进行AWR中的主要事件分析

CPU used by this session

统计CALL发起开始到结束的CPU时间片的数量，每个计数代表一个CPU周期，也就是10毫秒。不过如果有一个CALL不足一个CPU周期就执行完了，那么统计值的时候START TIME和END TIME是相同的，这样会计算为0.这个计数基本上可以代表了ORACLE数据库消耗的CPU资源，不过计算的时候要注意单位是厘秒(cs)，乘以10可以换算成毫秒。比如平均每秒这个指标值是782.1，表示ORACLE消耗了7821毫秒CPU时间，如果这个系统是一个16个CPU的系统，那么这个指标可以说明ORACLE消耗了超过50%的CPU资源。不过由于部分小的CALL可能由于消耗的时间小于10毫秒而没有计算进去，实际的使用率可能略高于通过这个值计算出来的。一般来说大多数CALL消耗的CPU都会大于10毫秒，所以这个值还是能够基本反映出ORACLE对CPU资源的开销

CR blocks created   

CURRENT块被克隆后用于创建CR（consistent read）块。被克隆的主要原因是BUFFER被非兼容的模式占用,如果单位时间内CR BLOCKS CREATED值比较高，说明数据库中对某些数据块的修改和访问比较频繁。如果这些访问集中在某些热块上，那么可能会形成较为严重的BUFFER BUSY  WAITS，在RAC环境中，可能还会导致全局热块冲突，如果这个指标比较高，那么应该关注BUFFER BUSY  WAITS以及CACHE BUFFER CHAINS闩锁等

current blocks converted for CR

一个CURRENT的BUFFER在被使用前生成了CR

DBWR buffers scanned

当某些触发条件发生时，DBWR会在LRU链的冷端开始扫描脏块，组成DBWR BATCH，这个指标统计的是DBWR在LRU上扫描的BUFFER的总数，包含脏块和干净的块，这个指标除以DBWR LRU SCANS这个指标就是每次扫描查找的数据块的数量。

DBWR checkpoint buffers written

CHECKPOINTS时dbwr写入的的脏块数量，如果在单位时间里这个指标比较高，说明系统中数据块的变更较为频繁

DBWR free buffers found

DBWR从LRU链中扫描BUFFER的时候发现的FREE的BUFFER的数量，除以DBWR  MAKE  FREE REQUESTS就是平均每次DBWR在收到DBWR MAKE FREE消息的时候扫描LRU链找到的FREE BUFFER的平均数，这个平均数一般会比较少

DBWR make free requests

DBWR收到的MAKE FREE 消息的数量，如果某个前台进程在查找一个空闲的BUFFER的时候无法找到的时候或者其他一些触发条件，会向DBWR发出MAKE FREE消息。如果在单位时间内这个值较高，说明DB CACHE可能存在不足的现象

DBWR summed scan depth

DBWR扫描LRU链查找脏块的时候，查找的BUFFER的数量，这个数越大说明LRU链尾部的赃块数量越少。从Oracle 8i开始，由于LRU链的算法发生了变化，因此如果LRU链尾部的热块比较多，也可能造成这个指标较大

DBWR timeout

DBWR IDLE超过一个特定值，该指标就会加1。如果该值较高，说明BUFFER CACHE中的数据变化较小，需要写入磁盘的脏块数量极少

DBWR transaction table writes

DBWR写入的回滚段头的数量，这个指标比较高说明有较多热块正在被写入，而大量用户进程在等待这些块写入完成

DBWR undo block writes

DBWR写入回滚段的数据块数量

DDL statements parallelized

DDL操作并发执行的计数

DML statements parallelized

DML操作并发执行的计数

background checkpoints completed

后台进程完成的CHECKPOINTS的数量。

background checkpoints started

后台进程启动的CHECKPOINTS数量，可能比上一个状态的值大一些。如果一个新的CHECKPOINT覆盖了一个未完成的CHECKPOINT或者CHECKPOINT还正在执行。这个状态只包含REDO的CHECKPOINT，不包括其他类型的CHECKPOINT，比如OFFLINE文件或者BEGIN BACKUP或者ALTER SYSTEM CHECKPOINT LOCAL命令等

branch node splits

由于插入数据导致的索引枝节点分裂的数量，这个指标较高说明目前存在索引产生了较多的枝节点分裂，可能某张表上的某个索引字段变化十分频繁，这种频繁的变化可能对某个应用的性能有较大的影响

BUFFER DEADLOCK

DB CACHE死锁的数量计数，如果单位时间内该指标较高，可能DB CACHE存在性能问题，或者存在某些BUG

buffer is not pinned count

当访问一个BUFFER的时候，这个BUFFER已经释放的数量，只用于Oracle内部调试，并不说明性能问题

buffer is pinned count

当访问一个BUFFER的时候，该BUFFER已经被PIN住了，如果单位时间内这个指标比较高，说明可能存在热块

change write time

当前块的变化被写入REDO的时间，单位厘秒（cs,10毫秒），该指标一般不会太大，如果太大需要分析

commit cleanout failures: block lost

在commit的时候准备做块清理操作的时候，发现不能找到正确的块的次数计数。

commit cleanout failures: buffer being written

Oracle在COMMIT的时候，去清除BUFFER的时候，发现这个BUFFER 正在被其他会话写入的计数，如果改指标比较高，可能说明存在热块  

commit cleanout failures: callback failure

Oracle在COMMIT的时候，做清除操作时调用CALLBACK函数返回FALSE的计数

commit cleanout failures: cannot pin

Oracle在COMMIT的时候，做清除操作时无法PIN到这个BUFFER的计数,有可能在准备清理的时候该BUFFER又被其他会话PIN住了，如果该指标较高，可以查看DB CACHE相关的情况，包括DB CACHE的大小，命中率，相关闩锁的命中率，以及热块争用的情况

commit cleanout failures: hot backup in progress       

Oracle在COMMIT的时候，做清除操作时发现正在做热备份的技术。此时在修改这个BUFFER前，这个BUFFER在被修改前，必须先被写入LOG BUFFER，以确保数据库恢复的时候不会产生块断裂

commit cleanout failures: write disabled

Oracle在COMMIT的时候，做清除操作时发现数据库的写操作暂时被关闭了。这种情况出现的很少

commit cleanouts

在做COMMIT的时候做块清除工作的计数，无论成功与否计数器都会加1

commit cleanouts successfully completed

COMMIT时成功完成CLEANOUTS的计数。这个指标和上一个指标参考来看，两个指标应该较为接近（这个指标略低一些），如果这两个指标相差太大，需要分析DB CACHE是否存在过小的问题，或者应用中是否经常对大表进行大数据量的修改操作

consistent changes

数据块提交了UNDO信息成为CR块的计数，这个指标说明了系统中CR块产生的数量，这个指标越大，越要注意CACHE BUFFER  CHAINS等闩锁的情况，以及热块对系统性能的影响

consistent gets

一致性读的计数，会话发出的对某个数据块进行一致性读的请求。这个指标不能和consistent  changes混淆，一个CR块产生后，可能被多次consistent gets使用，因此这个指标要比前一个指标大的多。

data blocks consistent reads - undo records applied

从UNDO中读取数据，形成CR READ。本计数器是记录从UNDO中获取UNDO记录的计数，如果这个指标的值较大，说明对于某些修改较为频繁的表的查询和其他操作也很频繁，有可能存在热点表和索引

deferred (CURRENT) block cleanout applications

做延迟块清除操作的计数。在提交的时候该数据块由于某些原因，某些数据块无法马上做块清除工作，这种情况下，这个数据块就会做延迟块清除，延迟块清除操作可能在下次该数据块被查询的时候进行，这种情况也导致了有时候我们会看到我们做SELECT操作的时候也会产生大量的REDO

dirty buffers inspected

当某个会话在LRU链的冷端开始查找空闲的数据块，查到一个脏块，这个指标就会被增加，如果在单位时间内该指标较大，说明LRU链的冷端存在较多的脏块。这种情况的出现有几种可能：

l          系统中的赃块数量十分巨大，而且DBWR的写入速度不足，从而导致DBWR无法尽快将这些脏块写入硬盘

l          部分BUFFER 特别热，并且被更改的频率特别高，从而造成LRU链的尾端存在大量这样的块

l          本系统是一个以DML为主的系统，数据块的变更十分频繁

碰到这种情况，可以关注一下dbwr的性能，并且关注一下DB  CACHE的命中率及cache buffer chains等闩锁的情况

enqueue waits

等待各种锁的计数

exchange deadlocks

当进行两个BUFFER交换的时候，发生内部死锁的计数。索引扫描是导致这种交换的唯一因素，如果改指标较高，可以检查是否存在十分热的索引（可以通过BUFFER BUSY  WAITS分析来定位）

free buffer inspected

从LRU队列的尾部扫描可重用的BUFFER的时候跳过的BUFFER的数量。

global cache freelist waits

当ping一个buffer的时候由于所有的lock element都被使用而引起的等待。

global lock convert time

同步全局锁的转换时间（单位是10ms），这个指标较高说明全局锁冲突较为严重，需要检查cluster  interconnect的性能

hot buffers moved to head of LRU

当一个热块到达LRU队列的尾部的时候，ORACLE自动会把这个块移动到LRU队列的头上，以便于使之能够继续被使用。每发生一次这样的操作，这个计数就加一，值得注意的是，从8i开始，LRU的算法发生了变化，通过引入TCH计数来确定热块，而不是通过将热块在LRU链上移动来保证热块不被过早的换出。如果热块存在于LRU链的尾部，扫描的时候发现了热块，会主动跳过，从而保证热块不被过早的重用

immediate (CURRENT) block cleanout applications

获取BUFFER（GET BUFFER）后，立即进行记录清除操作的计数。

leaf node splits

当INSERT发生后，导致索引叶节点分裂的次数，一般来说对于插入较为频繁的系统，这个指标一般会比较高，除非出现叶节点热块较为严重的现象，一般来所不需要特别关注该指标

logons current

当前登录数据库的计数

opened cursors current

当前的Open CURSORS的数量

opens of replaced files

文件由于不在打开文件缓冲中而重新打开的计数。每个Oracle会话都有一个文件打开缓冲区，保持部分打开的数据文件的句柄，以避免重复打开文件

parse count (hard)

硬分析的统计值，该值需要和parse count  (total)对比来看硬分析的比例。

parse count (soft)

软分析的统计值

parse count (total)

发生的parse call的总数

parse time cpu

PARSE消耗的CPU的统计，单位是10毫秒

parse time elapsed

PASE的持续时间，单位是10毫秒。这个指标减去parse time cpu就是parse中等待的时间。如果parse time cpu占整个parse time elapsed的比例较低，说明parse中的等待时间过长，可能共享池存在性能问题，需要进行分析

physical reads direct

直接物理读的数量。读的时候不经过BUFFER。一般发生这种操作的情况有：排序操作、并行查询操作的SLAVE或者预读

physical writes direct

直接写的数量，不经过BUFFER，直接写入。一般发生这种操作的情况有：

l          直接装载操作，比如CREATE TABLE AS SELECT

l          并行DML操作

l          排序操作中的临时表空间写入

l          写入没有缓冲的LOB字段

physical writes non checkpoint

非CHECKPOINT引起的物理写。物理写的发生情况包括CHECKPOINT或者无足够的空闲BUFFER可用，或者DBWR超时等，一般情况下这个指标会超过physical  writes的一半以上，除非是CHECKPOINT十分频繁的系统。如果该指标占physical writes的比重比较少，应该进行分析

pinned buffers inspected

当一个用户进程扫描REPLACEMENT列表，寻找一个可重用的BUFFER的时候，发现一个冷块被PIN了或者有一个PIN请求的等待事件。这种情况很少发生，因为冷块很少会被PIN。如果平均每秒该指标值较大，需要进行分析

queries parallelized

并行查询执行的次数统计

recursive cpu usage

非用户调用的CUP时间

recovery array read time

做recovery的时候产生的IO消耗的时间

recovery array reads

做RECOVERY的时候产生的IO的次数

recovery blocks read

做recovery的时候读取的数据块的数量

redo entries

当一个redo信息被拷贝到log buffer的时候这个计数增加

redo entries linearized

小于等于REDO_ENTRY_PREBUILD_THRESHOLD的redo entries的数量，这些redo entries可以并发生成，不需要受闩锁的限制，但是会增加CPU的消耗，在多CPU的系统中，这个值会比较高

redo buffer allocation retries

当申请REDO BUFFER的时候，重试的次数。一般来说重试发生的原因是REDO WRITER还没完成或者日志切换正在进行。如果该指标较高，说明REDO  LOG产生的频率很高，LGWR无法及时刷新LOG  BUFFER，可以考虑加大LOG BUFFER的大小。LOG  BUFFER一般可以为几兆到几十兆，不过由于很多数据库版本中存在BUG，因此不建议将LOG BUFFER设置的过大，一般来说30-40M对于绝大多数系统来说都是足够的了

如果是由于等待日志切换，那么可能是存在的问题包括：

l           REDO  LOG文件过小

l           REDO  LOG IO性能不佳

l          数据文件的IO性能不佳导致DBWR写入较慢

l          DBWR的数量太少，导致DBWR的写入性能不足

redo log space requests

当前ACTIVE的日志文件满了，Oracle必须等待日志切换完成后才能分配REDO LOG磁盘空间，就会产生这个等待。如果SGA的大小和日志文件的大小不匹配，并且系统中的COMMIT十分频繁。当日志切换的时，DBWR需要把已经提交的脏块也写入磁盘，在这些脏块写入磁盘完成前，日志切换不能完成。在这种情况下，这个统计值会比较高。

如果这个统计值较高，建议检查以下几个方面：

l           REDO  LOG文件的IO性能是否存在问题，如果log file parallel write的平均耗时较大，说明REDO LOG的写性能出现了问题，建议将REDO LOG放到性能更好的磁盘上，或者将REDO LOG文件独立存放，避免IO冲突

l           LOG  BUFFER的大小是否过小

l          应用软件中的提交可能过于频繁，建议采用批量提交的方式，而不要每条记录都提交

redo log space wait time

Redo log space requests的等待时间（单位厘秒），这个指标需要和上一个指标一起看

redo size

生成的所有redo的大小，单位是字节

redo synch time

Redo synch调用消耗的时间，单位是10毫秒（厘秒）

redo sync writes

一般来说redo信息生成后，会被拷贝到log buffer中，并不需要马上被写入redo log文件，lgwr会周期性将这些数据写入redo log文件。不过如果事务提交了，那么这些redo 信息必须马上被写入REDO LOG文件，这个时侯redo sync  writes计数器会增加

redo wastage

在把LOG BUFFER数据写入REDO LOG文件的时候计算的LOG BUFFER空闲的空间

redo writer latching time

LGWR获得每个COPY LATCH的时间（单位厘秒），如果该指标存在问题，需要检查REDO LOG文件的IO性能以及LOG BUFFER的大小是否足够，这个指标只有在LOG_SIMULTANEOUS_COPIES  > 0的时候才有意义

redo writes

LGWR将LOG BUFFER写入REDO LOG文件的计数

remote instance undo block writes

如果远程的实例需要读取某个UNDO BLOCK，需要这个实例先将这个“脏的”UNDO BLOCK回写，这个计数器就会增加

remote instance undo header writes

和上一个指标类似，只是写入的是UNDO HEADER

remote instance undo requests

由于要做CR从远程的实例中请求UNDO的数量，如果这个指标较大，说明RAC中的某些数据块经常在实例间进行共享，某个实例修改过的数据也正在被其他实例使用，这种情况下需要留意CLUSTER  INTERCONNECT的性能

rollback changes - undo records applied

当用户需要ROLLBACK的时候，提交的UNDO记录的数量，当事务需要回滚时，需要从UNDO中取出数据，并且提交到已被修改过的数据上，这个计数和系统中ROLLBACK的数量以及每次ROLLBACK的记录的数量有关

rollbacks only - consistent read gets

当用户需要进行CR READ的时候，提交的UNDO记录的数量，此时并没有BUFFER CLEAR操作发生。当进行一致性读的时候，也需要从UNDO中取出相关的数据，然后生成一个CR BLOCK，把这些数据提交到CR BLOCK上，这个时候这个指标就会增加。

rows fetched via callback

CALLBACK函数返回的记录数。该统计量仅仅用于内部DEBUG

session cursor cache count

会话CURSOR缓冲区的计数，只有当session_cached_cursors大于0的时候才有意义，如果这个值已经很接近甚至到达了参数中session_cached_cursors的值，那么说明这个参数可能需要加大

session cursor cache hits

这个指标也只有当session_cached_cursors大于0才有意义，会话直接从SESSION CURSOR  CACHE中找到某个SQL的计数，这个值可以看出CURSOR CACHE产生的作用，可以将这个值和parse  count(total)进行比较

sorts (disk)

磁盘排序的数量，如果平均每秒该指标的值较高，需要检查一下PGA_AGGREGATE_TARGET参数是否设置过低，或者*_AREA_SIZE是否设置过小（PGA手工管理模式）。检查该指标的时候，同时应该查看一下TEMP表空间的相关文件的IO性能，如果TEMP表空间文件的IO性能不足，需要加大PGA的配置来减少硬盘排序

sorts (memory)

内存排序的统计

summed dirty queue length

每次写请求发生的时候，脏数据块链表的长度总和除以写请求的次数，这个统计值越大，说明系统中需要回写的脏块较多

switch current to new buffer

将当前BUFFER移动到另外一个新的BUFFER，原有的BUFFER成为一个CR BLOCK，这种操作的次数

table fetch by rowid

通过ROWID访问表，这种操作一般是通过索引访问，还有一种情况是SQL直接通过rowid去访问某个表。

table fetch continued row

如果访问某一行数据，需要访问多个BLOCK，这个计数器就会增加。产生这种情况的一个很主要的原因是行链和行迁移，如果某个表的PCT_FREE设置不合理，可能导致UPDATE的时候产生行迁移，这样就会增加这个计数

第二种可能性是某一行计数的长度相对BLOCK SIZE来说过大，这样一行数据被存储在多个BLOCK中的机会就较大，这种情况下应该将这种表存放于更大的BLOCK SIZE的表空间中

还有一种可能性就是系统中访问带LOB字段的访问较多，因为大的LOB字段一般来说采用独立的SEGMENT存放，因此访问这种数据也会增加这个统计值

total file opens

被INSTANCE打开的文件的数量（包含数据文件、控制文件、REDO  LOG等）

transaction rollbacks

被成功回退的事务的总数

write clones created in background

如果当前的BUFFER正在被写入，那么后台进程或者前台进程克隆一个新的BUFFER，使原来BUFFER的写入可以继续进行

enqueue conversions

表或者行锁的转换统计

enqueue deadlocks

死锁统计

enqueue releases

锁释放统计

enqueue requests   

锁申请统计

enqueue timeouts

锁申请超时统计

enqueue waits

锁等待统计