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