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

本篇文章为大家展示了如何进行AWR中的主要事件分析，内容简明扼要并且容易理解，绝对能使你眼前一亮，通过这篇文章的详细介绍希望你能有所收获。

现在很多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	锁等待统计

上述内容就是如何进行AWR中的主要事件分析，你们学到知识或技能了吗？如果还想学到更多技能或者丰富自己的知识储备，欢迎关注亿速云行业资讯频道。

原创文章，作者：3628473679，如若转载，请注明出处：https://blog.ytso.com/200217.html

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

相关推荐

发表回复