故障类型
数据库异常等待事件之log file sync
现象错误号
数据库响应缓慢，并伴随大量log file sync 等待事件
故障描述
某客户数据库定期会出现log file sync 等待事件，本次故障出现在节点2上，在故障期间，节点2出现了大量的log file sync等待事件，我们结合故障时间段的AWR报告，分析并给出出现故障的原因。
故障原因分析
故障简述
故障期间，在分析2节点的AWR上，我们看到2节点出现较多的 log file sync等待事件：
Log file sync 的成因较为复杂，特别是在RAC环境下，涉及的原因较多，总的来说，有如下几个可能：
1. 磁盘IO 慢导致LGWR进程将redo buffer的信息写入redo log file速度慢。
2. 事务过度的提交，即应用程序过度commit或者rollback
3. 本地或者远程服务器CPU资源不足，导致LMS和/或者LGWR不能及时得到CPU调度，不能正常工作。
4. RAC 私有网络进程LMS同步commit SCN慢。
5. RAC 节点之间CR块传递。
6. 控制文件争用
7. ORACLE BUG.
从目前的日志分析结果看，我么认为主要的原因存在于2和4上即事务的过度提交及RAC的CR块争用严重上面，下面给出具体的分析原因。
从事务提交分析
从事务提交角度考虑log file sync：
在故障时间段，在2节点的AWR上：
故障时间段的log file sync 严重并且commit等待也较为严重，同时，我们检查数据库的提交次数：
在故障时间段，数据库的提交次数达到每秒的66.15次，redo产生每秒在1M左右，提交次数非常大，频繁提交在一定程度上严重影响了log file sync。
从RAC 节点的SCN 同步分析
在RAC数据库中为了一致性读，需要将Commit SCN同步/传播到所有的节点上，如果RAC私有网络性能差，或者远程服务器CPU资源不足，导致LMS和/或者LGWR不能及时得到CPU调度导致LMS同步commit SCN慢。进而引起log file sync等待。
在 AWR 中，反应 SCN 同步的信息如下：
从目前来看，节点间的SCN同步较为频繁，并且故障点的log file sync等待大量在SCN上：P2即为SCN值
DRM 加剧Log File Sync 延迟
对比问题时段和正常时段AWR中的“Dynamic Remastering Stats”部分，可以现问题时段DRM指标存在异常。
上图是问题时段的Dynamic Remastering Stats。
这是正常时段的Dynamic Remastering Stats。对比可以发现replayed locks sent在正常时段值为0，而在问题时候，每次DRM对应15,244.25次操作。
大量的DRM操作，会加大Commit时SCN传播的时间，造成log file sync加剧，建议关闭DRM，减少DRM操作。
关闭Commit 时Poll 方式
11G Oracle commit有两种方式，Poll和Post/Wait。11.2.0.4后，Oracle会自动在这两种方式间切换。这个特性叫做“自适应日志同步机制”。
在问题时段，如下图：
有问题时段，每秒有60.21次redo synch polls。而正常时段，如下图：
redo synch polls 和redo synch poll writes都是0。
Poll方式就是让多个提交的进程一起等一会，等更多的进程提交，一起写Redo数据到磁盘，这有助于提高LGWR写Redo的吞吐，但会造成log file sync延迟加大。建议设置_use_adaptive_log_file_sync参数为False，关闭“自适应日志同步机制”，让LGWR使用post模式。
解决方案
基于以上分析，我们给出如下建议：
1. 修改commit_logging为batch。修改参数可以显著提高commit时的吞吐，但Oracle不会等待写Redo数据完成，再返回“Commit成功”这样的返回信息，而是在Commit后立即给出“commit成功”这样的返回信息，因此即使在收到“Commit成功”信息后，仍有可能丢失数据。
2. 关闭DRM ：RAC的DRM在一定程度上加剧了两节点间数据的平衡
3. 设置_use_adaptive_log_file_sync参数为Flase，关闭“自适应日志同步机制”。此参数可以在线设置，不需重启数据库。
4. 检查LMS进程数量是否足够。
5. 检查系统CPU资源是否足够。
6. 检查RAC节点之间的私有通信是否正常。
7. 设置隐含参数_immediate_commit_propagation为false，禁用immediate commit propagation特性。
建议先修改2和3 操作观察log file sync是否改善。如果出现异常宕机时可少量丢失数据，也可以修改1，它将极大提高LGWR写Redo的性能。