如何进行AWR中的主要事件分析
本篇文章为大家展示了如何进行AWR中的主要事件分析,内容简明扼要并且容易理解,绝对能使你眼前一亮,通过这篇文章的详细介绍希望你能有所收获。
创新互联拥有10多年成都网站建设工作经验,为各大企业提供网站设计制作、成都网站制作服务,对于网页设计、PC网站建设(电脑版网站建设)、App定制开发、wap网站建设(手机版网站建设)、程序开发、网站优化(SEO优化)、微网站、申请域名等,凭借多年来在互联网的打拼,我们在互联网网站建设行业积累了很多网站制作、网站设计、网络营销经验,集策划、开发、设计、营销、管理等网站化运作于一体,具备承接各种规模类型的网站建设项目的能力。
现在很多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中的主要事件分析,你们学到知识或技能了吗?如果还想学到更多技能或者丰富自己的知识储备,欢迎关注创新互联行业资讯频道。
名称栏目:如何进行AWR中的主要事件分析
文章转载:http://pwwzsj.com/article/jdcgsc.html