3.2.2 其他相关的等待事件
  当进程需要向日志缓冲区里拷贝重做记录时，发现没有足够的可用空间时，则必须等待log buffer space事件。如果一个进程花费了太多的时间在log buffer space等待事件上，这通常是由于下面两个原因：
1) 日志缓冲区尺寸太小。对于一个繁忙的批处理数据库系统里，一个太小的日志缓冲区（小于512K）会导致进程等待log buffer space。

2) LGWR进程太慢了，这也就是物理I/O速度过慢。可以通过检查log file parallel write等待事件的平均等待时间来判断，如果大于10毫秒，则说明LGWR过慢。
可以通过增加日志缓冲区的尺寸或加快LGWR的进程来减少log buffer space等待事件。

  而较小尺寸的联机日志文件会引起log file switch completion和log file switch (checkpoint incomplete)
这两个等待事件。log file switch completion表示进程正在等待日志切换完成。而当应用程序产生很多重做，然后由LGWR进程非常快得写日志文件并进行日志切换时，这时DBWR进程还没有把脏数据块写入磁盘以通知checkpoint结束时，这个时候产生log file switch (checkpoint incomplete)等待事件。可以通过增加联机日志文件的尺寸来减少log file switch completion和log file switch (checkpoint incomplete)。

使用如下SQL来显示有关日志缓冲区的latch free的misrate是否很大。 

select name,gets,misses,to_char((misses/(gets+misses)) * 100,'990.99') misrate
from v$latch where name in ( 'redo allocation' , 'redo copy', 'redo writing')

   如果是redo copy的丢失率很严重，则可以考虑增加隐藏参数：_log_simultaneous_copies的值。该参数定义了redo copy latch的数量，该参数缺省为CPU数量的两倍。从8i起，该参数成为隐藏参数，因为不适合为系统增加过多的redo copy latch，特别是在OLTP环境中。增加该参数可以减少前台对redo copy latch的等待，但是要注意，过多的redo copy latch可能会使得LGWR等待更长的时间。因为前面我们已经知道，LGWR在确定了要写哪些日志块以后，会等待前台进程完成对这些日志块的操作以后，才开始正式写入。所以，如果很多的前台进程都可以获得redo copy latch以后，就可能引起LGWR要等很长时间才能开始正式写入。

  如果是redo allocation的丢失率很严重，需要考虑是否有可能减少重做记录的生成。具体可以看下面有关如何减少重做记录的部分。8i以前，存在一个参数：log_small_entry_max_size，该参数说明了当重做记录的尺寸小于该参数指定值时，使用redo allocation latch来保护重做记录拷贝到日志缓冲区的过程，否则，如果重做记录大于该参数值时，使用redo copy latch来保护这个过程。但是从8i以后，取消了该参数，只要拷贝重做记录到日志缓冲区，就获得redo copy latch。

如果是redo writing的丢失率很严重，则说明LGWR写的时间过长，导致其他进程无法获得该latch。这时可以通过减小_log_io_size来增加LGWR写的频率。具体_log_io_size的用法可以参考下面log buffer的设置部分。