大概一周以前，我所在的项目出现了一个故障，某一个小型的监控系统hang。这个故障客户找到跟我一起驻场的另一个同事 处理。整整一个下午，他都在处理这个故障。而此前，这个故障出现过一次，当时也是处理了一个下午，通过重启暂时缓解了故障。
是什么故障这么棘手？快下班了，我也跑过去围观他的操作。由于操作的人不是我，以下是无数据无截图的回忆过程。
首先，我得到的第一个信息是，联机重做日志除了当前日志，全部active。日志无法切换，这种情况下，系统肯定是会hang住的。或许是系统产生的日志过多？同事告诉我，redo加了也没有效果，只要加上，马上就会满。这很奇怪，因为这个系统是个小型的监控系统，事务不会很多。
接下来他运行了we脚本，我看到了非常重要的一个信息：top 1 event 是free buffer waits。这是一个异常等待事件，不过还好，它并不复杂。这个等待事件出现的原因很简单，服务器进程们在等待足够多的buffer cache空间。要么buffer cache太小了，不能满足系统需要。要么io问题，buffer写出太慢。还有另一种，是SQL该优化了。综合redo的表现，原因已经很明显了：buffer写出太慢。因为日志切换会触发检查点。oracle使用的是不完全的模糊检查点，它的主要作用，就是把checkpoint queue中的部分buffer刷新到磁盘。如果是由于Buffer cache太小导致的故障，按理说，这个操作会让buffer cache的空间腾出来，正好满足服务器进程的需要。但是并没有，它们仍然在等待。所以真相就是：io太慢了。可能是系统本身的io瓶颈，也可能是dbwn进程太少了，忙不过来。iostat表明，io并不高。于是我提议把DBWR进程再加一些，他show了一下db_writer，发现这个系统的DBWR进程只有可怜的1个。他把它修改为4个，重启系统后，观察了一小段时间，free buffer waits等待消失，系统也变得很流畅了。
