现在很多DBA都阅读和分析STATSPACK/AWR报告，不过这份报告可不容易读。一般的DBA顶多能够看看前面的TOP EVENTS，命中率以及后面的一些ADVISORY，而实际上系统的更多的秘密存在于那些看起来十分生涩的InstanceActivity Stats中。但是对于这些STATS，大多数DBA都感到很无奈，没有任何官方的资料披露这些STATS的含义，有些DBA经过长年的积累，可以从字面意思上对某些指标进行一些解读。这些年里，老白阅读了数千份的STATSPACK/AWR报告，经过长期的积累，老白总结了一些阅读STATS的经验，在本节，将拿出来和大家分享。
经常有DBA问老白某某指标多大是不正常的，实际上由于每个系统的硬件配置、应用、周期性节奏等方面都存在不同，因此绝大多数数据库的指标都没有一个“正常值”。当然对于那些接触过大量系统的老DBA，他们可以根据经验，一打眼就看出某些指标不太正常，但是对于绝大多数DBA来说，看到这些指标就像看天书一样，哪怕知道这些指标的含义，也无法使用这些指标来分析数据库的问题。在这里老白可以向大家透漏一个十分有用的方法。
这个方法实际上也很简单，就是老白常说的基线对比的方法。对于一个系统，如果你为何的时间越长，越了解系统的脾气，那么这个系统出现问题的时候你处理起来越得心应手。而一个新系统，很多DBA可能觉得好像无从入手，很难摸到头脑。这是什么原因呢？实际上，一个你接触多的系统，在你的心理已经对这个系统建立了很多基线指标，这样的话如果系统出了问题，你就很容易通过和平时的比较找到问题。实际上你已经在实际工作中使用了老白所说的基线对比方法。基线对比方法的基础是对某个系统通过一段时间的信息采集，将其重要的系统指标建立基线，然后将出问题的时候的系统状态数据和基线的数据进行比较，从而发现问题。DBA分析AWR报告的时候，最好的办法是对比平时这个系统这些指标的平均值、合理的高值和低值这些指标，而不是孤立的从某一份报告中去查找问题。
另外一个要注意的问题是，AWR报告中的指标之间是相互关联的，在分析这些指标的时候，需要综合分析，将这些指标和其他的数据对比分析，才能够得到较为准确的分析结果，比如说你从某些指标上看出可能DB CACHE存在问题，那么你就需要比对报告头中的DB CACHE命中率情况，以及事件明细中的db file sequential read、db file scattered read等指标中的平均等待时间，如果DB CACHE的命中率较高，但是db file sequential read的平均等待时间较大，那么也不能说DB CACHE就一定没有问题，我们可以继续通过后面的Buffer Pool Statistics等信息来分析BUFFER CACHE是不是配置不合理，以及如何优化。
附表是AWR/STATSPACK报告中的主要指标的描述，该表可以作为DBA的一个参考资料来使用，没必要每个指标都去认真研读，也不必要把这张表的内容背诵下来。这张表中的内容大部分是老白这些年研读STATSPACK报告体会出来的，并不是来自于官方的说法，因此可能部分描述也不很准确，如果大家对老白对这些指标的解释有什么疑问，欢迎到www.oraclefans.cn上去和老白探讨。
|
名称
|
注释 |
| 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 |
锁等待统计 |
