处理log file sync等待事件

首先明确什么是log file sync等待事件

从用户提交会话开始，LGWR进程将redo缓存中的信息写入redo日志文件后，LGWR进程通知用户写操作完成，到用户会话接受到LGWR进程通知为止，这整个过程就是可能出现log file sync等待事件的地方。在LGWR写入日志过程中，还包括了控制文件修改操作，对于RAC节点，可能还存在节点之间的scn同步、节点之间cr块的同步。

引起log file sync等待事件的原因

1、事务提交数量过多，导致LGWR进程的任务变多，任务变多就可能产生资源的竞争，包括cpu、io、内存等的竞争，自然的LGWR速度就变慢，产生了log file sync等待事件。
2、存储io资源紧张，使得LGWR在进行物理写的时候速度变慢。
3、cpu资源紧张，导致LGWR获取不到cpu。
4、对于RAC架构数据库，为了实现不同节点数据一致性，需要将commit SCN同步到其他节点上，有两种同步方式：1)一个节点上的SCN不立即同步到其他节点，可以理解为异步SCN。2）BOC方式，一个节点的SCN需要通过本地实例的LMS进程，将SCN同步到远程实例的LMS进程，等待远程实例的LMS进程通知本地LMS同步完成后，再由本地LMS进程通知LGWR进程所有节点的SCN已经同步完成。这一步骤包含在了LGWR进程写入日志的过程中，如果SCN同步速度较慢，消耗时间较长，就会导致LGWR进程通知用户会话提交完的时间变长，也就是造成了log file sync等待事件。
5、RAC架构数据库，节点1提交事务之后，需要在本地实例上完成LGWR写入日志后，才能由LMS进程将cr块传递到其他节点上。节点2要读取这个block时，需要从有这个block的节点把cr块传递过来，节点2等待节点1传递的cr块的时间较长时，就会发生gc cr block busy。如果节点2在等待节点1传递某个block的过程中，节点2上又有其他的会话需要读取这个block，就会在节点2上发生gc buffer busy acquire。
6、控制文件争用。
7、提交方式

解决log file sync等待事件

从awr报告的Top 10 Foreground Events by Total Wait Time中发现log file sync等待事件后，就可以根据上面列出的引起log file sync等待事件的原因进行排查。
1、针对事务提交数量过多，检查故障时间段awr报告中Key Instance Activity Stats部分的user commits，对比非故障时间段的数值是否有一个大的变化，再对比下每秒的redo size大小是否有变化，确定是由于事务提交过多导致，那么就可以接着分析为什么事务提交数量会变多、近期有做过什么变更、应用端在故障时间段是否有跑批之类的业务、insert和update语句是row by row还是批量执行。
2、针对存储io资源紧张问题，首先检查故障时间段操作系统io的繁忙程度，具体到每块盘的io使用率；通过如下命令

SQL> select event, wait_time_milli,wait_count  
from v$event_histogram  
where event = 'log file parallel write';

检查log file parallel write等待事件和log file sync等待事件的时间差，如果log file parallel write等待事件时间和log file sync时间相差不大，说明就是数据库在进行物理块读写时速度慢。
经过前面的检查，确认是存储io问题之后，需要进一步排查物理盘是否有损坏、是否可以将不同表空间放置在不同盘上，比如将data、archive log、redo、ocr分别放置在不同的盘上，尽量避免高峰期时io资源的争抢；考虑是否是同一个集群上其他数据库io占据存储带宽，导致该数据库获取不到io。
3、针对数据库获取不到cpu的情况，首先从awr报告Load Profile部分检查DB CPU占据DB Time的比重，再检查操作系统在故障时间段cpu使用率，可以确定数据库是否出现cpu资源争抢。但出现cpu资源争抢可能只是表象，还有更深层次的原因，比如说并发连接数量冲高导致cpu竞争、批量中是否有通过row by row 的dml语句等。