这个等待事件在繁忙的系统很容易出现，要想解决这个问题就得了解为啥会出这个问题。
说到redolog就必须得说下oracle 日志体系，oracle 默认必须有3组日志，每组日志是循环写的，oracle在写入数据的时候肯定是先写日志后写数据文件，一旦写日志出现了等待，那么系统肯定会非常慢，影响很大。redolog日志比较特殊，它是顺序写入的，所以oracle官方也不建议把redolog方在asm条带化存储中。我们知道在文件系统层面的顺序写对应磁盘就是随机IO，所以SSD盘对随机IO提升效果不大，条带化的存储对顺序写的文件效果也不大。
回到oracle数据库上来，如果数据库开了归档，那么一条数据从redlog buffer写到redolog，这个过程期间也会产生等待，最典型的就是redolog sync 和redolog paralle write 。
Log File Sync是从提交开始到提交结束的时间。Log File Parallel Write是LGWR开始写Redo File到Redo File结束的时间。 Log File Parallel Write 也会影响 Log File Sync。 这边log file sync 平均等待时间是 1MS， 后文中Log File Parallel Write 也是1ms 因此判断系统IO没有问题。
如果 此时Log File Parallel Write 平均等待时间件很高， 这种情况一般是IO出问题了，导致log 写到磁盘缓慢。
如果 Log File Sync的平均等待时间很长，但是 Log File Parallel Write 时间很短，这种情况查一般检查2点。
1 commit的进程和lgwr之前通过CPU调度来协调的， 会不会CPU资源紧张导致协调过慢？ 如果是的。那就会伴随逻辑读高，块忙， latch....等待事件反应CPU吃紧， 这份AWR报告中并没有这样的特征。 另外host cpu idle 上面也没有反应CPU吃紧。
2 如果日志缓冲区太小，导致一次写入的量很大，也会导致这种现象。
通过AWR报告，已经系统系统查询并不是以上几点。
此时不妨停下来思考一下，什么是log file switch (checkpoint incomplete)？
log file switch (checkpoint incomplete)指的是当redo需要向下一组redo group切换的时候，发现下组日志是active的，也就是说下组日志中对应的一些buffer cache中的脏块尚未写入到数据文件中，因此必须等待这些脏块被完毕后，才可以复用下一组redo group。如果数据库开了归档，那么这时候这个日志组必须得先写归档才能被覆盖，这个时候数据库就处于假死状态。
解决这个问题一般有几个方法：
1、增加redolog group 数量；
2、增加dbwr的进程；
3、提高磁盘IO能力；
来源：oschina
链接：https://my.oschina.net/u/3862440/blog/3004311