反馈:4月11日9点钟上班时,发现系统很慢,你使用脚本查到有锁表的问题,然后你对session进行kill,系统恢复正常。
原因分析:
下面4:00-6:00的数据库报告的TOP5的等待事件,数据库版本是10g,cpu是4个。
Event | Waits | Time(s) | Avg Wait(ms) | % Total Call Time | Wait Class |
---|---|---|---|---|---|
log file sync | 192,156 | 18,743 | 98 | 46.9 | Commit |
RMAN backup & recovery I/O | 7,077 | 7,915 | 1,118 | 19.8 | System I/O |
db file sequential read | 40,557 | 7,424 | 183 | 18.6 | User I/O |
read by other session | 15,306 | 7,025 | 459 | 17.6 | User I/O |
SQL*Net more data to client | 37,819 | 2,595 | 69 | 6.5 | Network |
同时伴随着log file parallel write的等待事件:
log file parallel write | 883 | 2,398 | 2716 | 0. |
分析了11日0:00-10:00的数据库报告。发现凌晨4点钟开始数据库就有问题了。等待事件log file sync在4:00-6:00等待总时间为18,743s,等待192,156次,平均等待时间98ms。log file sync这个等待事件十分关键,我们日常做数据库维护的时候,应该对此指标建立基线,一旦这个指标有异常变化,一定要尽快进行分析并解决问题。一旦这个指标恶化,可能导致系统性能急剧下降,甚至导致短暂的HANG住。当log file sync平均等待时间超过20ms就要开始预警,可以看到4:00-8:00之前的报告,log file sync平均等待时间远大于这个值,说明数据库写redo log的磁盘读写速度达到了极限。现场反馈的表被锁只是表象,log file sync等待时间变长会导致系统所有的事务提交变慢,锁释放变慢;你后续的处理使系统恢复正常,属于巧合,其实是数据库的redo写的能力变恢复正常了。
还有rman备份的时间过长,rman是要反复读取数据块的,防止块裂,所以它会严重的占用磁盘读资源,也就是影响磁盘的吞吐量,从user commit和user rollback来看,事务量比起上一个时间点有所增加,这也符合一般系统的规律,8点以后开始上班,所以事务量增加,系统响应开始出现问题。
解决方案:
第一:调整rman备份策略。rman在8点前一定要备份完成,可以采用增量备份的方式,
第二:提升的磁盘读写能力,写redo log换用更快的raid来解决这个问题。据我猜测,redo的磁盘很可能用的是文件系统,也许是单个磁盘,才导致了这么差的性能,或者是redo和rman的磁盘放在一起了。