2013-04-11 log file sync等待造成系统不可用

        反馈：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的磁盘放在一起了。