检查数据库报告，发现log file sync 平均等待已经超过20ms，说明DML提交很慢，很可能磁盘比较慢。先查看IOStat by Function summary，确认一下数据库整体IO的情况。然后分析Segments by Physical Reads、Segments by Direct Physical Writes，是否有消耗占比大的对象。如果有则优化对应的sql。@H_502_3@
如果以上问题都没有，还有可能redo log切换太频繁也会导致慢。因为DML commit需要写了redo log才算成功，而在切换在线redo log时，在线redo log要传到归档空间之后，在此期间commit都是要等待的。查看log switches,一个小时52次太频繁了，正常一个小时切换1到2次。@H_502_3@
Instance Activity Stats - Thread Activity@H_502_3@
- Statistics identified by '(derived)' come from sources other than SYSSTAT@H_502_3@
| Statistic@H_502_3@ | Total@H_502_3@ | per Hour@H_502_3@ |
|---|---|---|
| log switches (derived)@H_502_3@ | 156@H_502_3@ | 52.04 @H_502_3@ |
1.产生了大量的redo,这个可以通过Report Summary中的Redo size (bytes)计算得出。再根据redo log设置的大小，看切换次数是否正常。正式环境一个redo文件设置的是1G,而根据Report Summary@H_502_3@计算出来的才产生的redo 2G,那就是redo log没有被写满就切换了。@H_502_3@
2.如果根据Report Summary@H_502_3@计算出来的的redo的量就是很大，假设有52G，那就得看Segments by DB Blocks Changes、Segments by Physical Writes、Segments by Direct Physical Writes，找到占比大的对象。@H_502_3@@H_502_3@
3.人工执行日志切换命令，看起来不可思议，rman增量备份的时候调用了日志切换，这个环境就是这个问题。@H_502_3@
