当用户会话（前台过程）提交（或回滚）时，会话的redo信息须要刷入到重做日志文件中。 用户会话将应用LGWR来将日志缓冲区中所需的所有redo申请写入重做日志文件。当LGWR实现后，它将告诉用户过程。用户会话将呈现该期待事件，同时期待LGWR将其回发以确认所有重做更改都平安地在磁盘上。

换句话说，用户会话/前台过程破费的工夫期待刷新重做以使得commit期待更长时间。因而，咱们能够将这些期待视为来自前台过程（或通常的提交客户端）的提交提早。

该期待事件越多，可能阐明LGWR的写效率低或者零碎提交（回滚）过于频繁。通常产生在OLTP零碎上。

对于本身范畴内产生的期待

  1. 查看动静性能视图V$SESSION_WAIT波及到的“log file sync”参数

P1 = buffer#

P2 = not used / sync scn

P3 = not used

注：

buffer#：此缓冲区编号（在日志缓冲区中）的所有更改都必须刷新到磁盘并确认写入以确保事务已提交，并且将在实例解体时放弃提交。因而期待LGWR刷新到此buffer#。

sync scn：10.2.0.5.0及更高版本会应用到。示意须要同步到磁盘的SCN值的根底。期待LGWR刷新SCN值。

  1. 等待时间

期待齐全依赖于 LGWR写出到必要的重做块并确认实现返回用户会话。等待时间包含日志缓冲区的写入和post。在某些版本中，waiter超时并在期待时每隔一段时间减少序列号（旧版本中间隔时间是以1秒为单位，新版本中游戏自适应）。

  1. 寻找“Blockers”

如果会话持续在雷同的buffer#上期待，则V$SESSIONwww.cungun.comIT的SEQ#列可能会减少，具体取决于所应用的期待计划。如果buffer#值没有扭转，须要查看看看LGWR正在期待什么，因为它可能被卡住了。还要查看期待过程是否还活着。

对于零碎范畴内产生的期待

“log file sync”上期待的零碎范畴的数字显示了期待提交（或回滚）实现所破费的工夫。如果这很重要，那么LGWR可能存在问题。还须要关注：

  1. LGWR的另一个期待事件"log file parallel write"
  2. “user commit”和”user rollback”的统计信息，查看正在收回的提交和回滚的次数。

缩小期待和等待时间的办法

有五个办法能够缩小该期待事件的工夫：

  1. 调整 LGWR 取得更好的磁盘吞吐量。如： 不要将重做日志放在RAID 5上，因为RAID 5对于频繁写入的零碎会带来较大的性能损失。
  2. 如果有很多小事务，看是否能够将事务BATCH放在一起，从而缩小不同的COMMIT操作。 每次提交都必须确认相干的REDO刷到磁盘上。只管Oracle能够“piggybacked”提交，但通过批处理事务来缩小提交的总数会产生十分好的成果。
  3. 查看是否有任何解决能够应用COMMIT NOWAIT选项（但在应用之前肯定要理解它的语义）。
  4. 查看是否能够应用NOLOGGING / UNRECOVERABLE选项平安地实现任意操作。
  5. 查看重做日志是否足够大。增大重做日志，使日志在15到20分钟之间切换。

另外，日志文件同步期待的总工夫能够细分为以下几种：

  1. 闲暇时唤醒 LGWR
  2. LGWR收集要写入的redo操作并收回I/O申请
  3. 日志写I/O实现工夫
  4. LGWR I/O开始工作
  5. LGWR告诉写入实现的前台/用户会话
  6. 前台/用户会话唤醒