系统层面的IO你怎么看的。具体多少呢。

通过NMON分析的。

我查的资料说如果log file sync和log file parallel write相差很大就说明IO不是瓶颈。
通过awr看到log file sync总共等待64,414次，平均等待11ms，log file parallel总共等待78,342次，平均等待只有1ms。

找一个正常时间的AWR上传上来吧。比如前天晚上相同时间段的。
还有对比下，10号和11号的日志切换次数。

IO量不大，甚至非常小。
你能不能在提供一下IO的读写延迟。这个其实是看io的重要指标

可能看延迟也看不出来。
或者看看lvm有没有闪断过之类的

提供一下00-01的osw或者nmon日志看看

双11点0-1点比较特殊，再找不到类似的了。通过alert没发现redo有切换操作。nmon 生成的excel见附件

双十一也就是业务高峰么？可以在测试环境模拟测试，现场监控下等待事件，系统负载的变化。

另外，我们再最佳实践里面一般都设置了_use_adaptive_log_file_sync参数，可以参考下。

alter system set "_use_adaptive_log_file_sync"=false sid='*' scope=spfile; 

说明：11.2.0.3 版本里面，这个参数默认为 true，LGWR 会自动选择两种方法来通知其他进程 commit 已经写入：post/wait、polling。前者 LGWR 负担较重，后者等待时间会过长，特别是高负载的 OLTP 系统中。在 10g 及之前的版本中是 post/wait 方式，将这个参数设置为 false恢复到以前版本方式。

这种问题如果不是BUG，一般通过提升I/O来解决，或者是改代码批量提交，减少commit次数。

0点24分的业务没刚过0点的业务多，最忙的时候反而没log_file_sync等待。听章工这么一分析我猜应该是那个隐含参数引起的等待抖动。这个参数我看在11.2.0.4也是默认开启的，可惜不好验证。

我刚去生产确认了下，这个隐含参数他们已经修改过了。_use_adaptive_log_file_sync=0