故障情况

AWR报告如下：

之后他们把大部分业务停掉后，Log file sync等待事件还是非常高。

通过对比昨天跟今天相同时间的AWR，在业务量小非常多的情况，等待时间还是高非常大。

诊断过程

log file sync等待事件首先判断当前系统IO是否存在问题，看操作系统日志没有相关的报错，执行IO测试，也显示IO处于正常状态，详细查看AWR报告，AWR显示数据库写IO及读IO都还比较正常。对比昨天跟今天的AWR报告，也可以看出IO读写性能跟昨天相比差别不大，今天采集的这个时间段由于停了大部分业务，IO相比昨天反而更优，但是日志切换的等待时间反而要增加8秒。

根据Tanel Poder前辈写的《Log file sync,LGWR》诊断手册里的Commit log file sync flow

从上图中，我们可以清楚的看到commit整个流程。

1、当user发起一个commit后；

2、前端进程（即Server 进程）会post一个信息给lgwr进程，告诉它去写redo buffer。

3、当LGWR进程得到指示后，开始调用操作系统函数进行物理写，在进行物理写的这段时间内，会出现log file parallel write等待。

4、当LGWR完成wrtie操作之后，LGWR进程会返回一个信息给前端进程（Server进程），告诉它，我已经写完了，你可以完成提交了。

5. user 完成commit操作。

从上面的流程图，结合AWR 里log file parallel write及用户IO及系统IO的等待时间都很短，因此我们可以判断问题不是出在IO性能上。那么问题应该出在阶段2及阶段5上。

根据mos文章：

《Troubleshooting: 'Log file sync' Waits (Doc ID 1376916.1)》

《Adaptive Log File Sync Optimization (Doc ID 1541136.1)》

《Adaptive Switching Between Log Write Methods can Cause 'log file sync' Waits (Doc ID 1462942.1)》

发现Oracle11g 之后Oracle新推出一种日志同步方式，称为自适应方式，在Oracle 11.2.0.3版本之后启用这个特性

Initially the LGWR uses post/wait and according to an internal algorithm evaluates whether polling is better. Under high system load polling may perform better because the post/wait implementation typically does not scale well. If the system load is low, then post/wait performs well and provides better response times than polling. Oracle relies on internal statistics to determine which method should be used. Because switching between post/wait and polling incurs an overhead, safe guards are in place in order to ensure that switches do not occur too frequently.

根据文单的描述，检查系统的负载情况，发现今天业务系统在14点时负载很高，日志切换达136次，之后业务恢复正常

检查当前的系统，发现当前系统LGWR正采用Polling方式。

SQL> select name,value from v$sysstat where name in ('redo synch poll writes','redo synch polls');

redo synch poll writes 6248

redo synch polls 8843

故障原因分析

由于业务系统在14点时负载变为非常高，因此Oracle把LGWR写方式切换为Polling方式，以保持更高的性能，但是当业务负载降下来时，正常情况下LGWR应该切换回原有Post/wait 方式，但是这次没有切换，还一直采用Polling方式。判断碰到BUG，没有切换，因此导致性能变差(网上文章写polling的间隔是10ms，Post/wait 的间隔是1~2ms，在mos上没找到文章有写这个时间)