等待事件 log file sycn见解

来新公司工作，很大的一段时间都在着手调优日志，提升系统的性能，在这方面也积累了一些理论知识和实践经验，之前零零散散在微博上也发了很多关于log file sync的帖子，篇幅都很短，有些是自己优化系统过程中的一个心得，有些是看书过程中的一点感悟，这次把他们汇集起来，变得也更有可读性一些，作为自己的一个总结，也希望里面的内容也或多或少能够帮助到你。
log file sycn是ORACLE里最普遍的等待事件之一，一般log file sycn的等待时间都非常短 1-5ms，不会有什么问题，但是一旦出问题，往往都比较难解决。什么时候会产生log file sync等待？
常见有以下几种：
1)commit操作
2)rollback操作
3)DDL操作（DDL操作实施前都会首先进行一次commit）
4)DDL操作导致的数据字典修改所产生的commit
5)某些能递归修改数据字典的操作：比如查询SEQ的next值，可能会导致修改数据字典。一个典型的情况是，SEQ的cache属性设置为nocache，那么会导致每次调用SEQ都要修改数据字典，产生递归的commit。

一个正常的系统里，绝大多数的log file sycn等待都应该是上面描述的1）commit操作 造成的log file sycn等待，某些异常的系统，比如频频rollback、seq的cache设置为nocache的系统，也可能会造成比较多的log file sycn等待。

我们要是能知道log file sync包含哪些环节，再有针对性的优化各个环节，就能事半功倍了。

上面是Tanel Ponder画的log file sync等待事件的延迟图，在某些关键环节上打了点。我对其中打点的环节，稍作翻译如下：
1)用户进程发起commit
2)用户进程通知lgwr写日志
3)lgwr接收到请求开始写
4)lgwr写完成
5)lgwr通知用户进程写完成
6)用户进程获得通知，继续做其他事

1,2阶段的时间，主要是post/wait的时间，典型的这种post/wait一般利用的是操作系统的信号量（IPC)实现，如果系统CPU资源充足，一般不会出现大的延迟。前台进程post lgwr后，就开始等待log file sync。
2,3阶段的时间，主要是lgwr为了获取cpu资源，等待cpu调度的时间，如果系统cpu资源充足，一般不会出现大的延迟。这里我们需要知道，lgwr只是操作系统的一个进程，它需要操作系统的调度获取cpu资源后才可以工作
3,4阶段的时间，主要是真正的物理io时间，lgwr通知os把log buffer的内容写入到磁盘，然后lgwr进入睡眠（等待log file parallel write），这个时间正常情况下的延迟占整个log file sync的大部分时间。还需要指出，lgwr在获取cpu资源后，可能并不能马上通知os写磁盘，只有在确保所有的redo copy latch都已经被释放，才能开始真正的IO操作。
4,5阶段的时间，os调度lgwr 重新获得cpu资源，lgwr post前台进程写完成。lgwr可能会post很多前台进程(group commit的副作用)
5,6阶段的时间，前台进程接受到lgwr的通知，返回cpu运行队列，处理其他事物（log file sync结束）。

/*************************************************什么是group commit************************************************/
不止一次的看到过一些对log file sync调优的建议里写着：打开ORACLE的组提交功能。
group commit默认就是开启的，而且你没有任何手段可以关闭它!
我一直认为group commit这个东东起的名字不是太过恰当，应该起组刷新更恰当，仅仅代表个人意见。
什么是组提交？

上图是log buffer的抽象图，log buffer此时是非常繁忙的。
给大家设定这样一个场景。
c1作为一个commit record已经被copy到了log buffer里，接着前台进程通知lgwr去写日志，根据我前面的描述，在前台进程post lgwr去写，到lgwr真正开始写之前，非常可能存在着时间差，就在这个时间差里，c2,g1,c3也已经把相应的日志拷贝到了log buffer里，其中c1,c2,c3是commit的记录，g1仅仅是普通的事务日志，不是commit日志。在lgwr真正开始写之前，它会去检查当前log buffer的最高点，发现在c3位置处，把这个点作为此次刷新日志的目标，把c1,c2,g1,c3的日志都刷新到磁盘。虽然刷新日志这个操作是由c1出发的，但是c2,g1,c3也是受惠者搭了便车，日志也被刷新到了日志文件里，这个功能叫组提交，对于一些不太熟悉ORACLE的人容易把组提交误解为，把提交的事物打包刷新到日志里，其实LGWR是不管你的事务日志有没提交的，它只按照log buffer分配的最高点来刷新，因此我觉得叫组刷新更好点。
图中c1,c2,g1的日志已经拷贝完成，我用filled表示，c3的日志空间已经分配，但是还没完成拷贝，我用allo表示，这个情况下，其实lgwr需要等待c3日志拷贝完成，才能真正的开始刷新操作。
/*************************************************什么是group commit************************************************/

我们剖析了log file sycn的各个阶段后，可以看出，正常情况下，最慢的环节应该在3,4阶段（如上图），典型的io操作，这个环节对应的数据库等待叫做log file parallel write。其他的阶段如调度延迟、IPC时间一般都是极短的。网上、论坛上、包括不少书籍里，很多在log file sync出现问题后，往往都把责任推卸到IO慢的原因上。绝大多数情况下，这样的推断可能都是正确的，但是，事情不总是这样的，就像我们分析的，log file sync的快慢也是很依赖cpu资源是否富足、系统的负载是不是过大。我们再看下一幅图，这副图描述了，在CPU资源不足的情况下，各个阶段占取整个log file sycn的比重。

如你所见，由于CPU资源的不足、系统负载过大，导致操作系统调度出现了较大的延迟，3,4阶段的IO部分的延迟已经不是整个log file sync时间的最大的罪魁祸首！