当用户会话（前台过程）提交（或回滚）时，会话的 redo 信息须要刷入到重做日志文件中。用户会话将应用 LGWR 来将日志缓冲区中所需的所有 redo 申请写入重做日志文件。当 LGWR 实现后，它将告诉用户过程。用户会话将呈现该期待事件，同时期待 LGWR 将其回发以确认所有重做更改都平安地在磁盘上。
换句话说，用户会话 / 前台过程破费的工夫期待刷新重做以使得 commit 期待更长时间。因而，咱们能够将这些期待视为来自前台过程（或通常的提交客户端）的提交提早。
该期待事件越多，可能阐明 LGWR 的写效率低或者零碎提交（回滚）过于频繁。通常产生在 OLTP 零碎上。
对于本身范畴内产生的期待
- 查看动静性能视图 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 值。
- 等待时间
期待齐全依赖于 LGWR 写出到必要的重做块并确认实现返回用户会话。等待时间包含日志缓冲区的写入和 post。在某些版本中，waiter 超时并在期待时每隔一段时间减少序列号（旧版本中间隔时间是以 1 秒为单位，新版本中游戏自适应）。
- 寻找“Blockers”
如果会话持续在雷同的 buffer#上期待，则 V$SESSIONwww.cungun.comIT 的 SEQ#列可能会减少，具体取决于所应用的期待计划。如果 buffer# 值没有扭转，须要查看看看 LGWR 正在期待什么，因为它可能被卡住了。还要查看期待过程是否还活着。
对于零碎范畴内产生的期待
“log file sync”上期待的零碎范畴的数字显示了期待提交（或回滚）实现所破费的工夫。如果这很重要，那么 LGWR 可能存在问题。还须要关注：
- LGWR 的另一个期待事件 ”log file parallel write”
- “user commit”和”user rollback”的统计信息，查看正在收回的提交和回滚的次数。
缩小期待和等待时间的办法
有五个办法能够缩小该期待事件的工夫：
- 调整 LGWR 取得更好的磁盘吞吐量。如：不要将重做日志放在 RAID 5 上，因为 RAID 5 对于频繁写入的零碎会带来较大的性能损失。
- 如果有很多小事务，看是否能够将事务 BATCH 放在一起，从而缩小不同的 COMMIT 操作。每次提交都必须确认相干的 REDO 刷到磁盘上。只管 Oracle 能够“piggybacked”提交，但通过批处理事务来缩小提交的总数会产生十分好的成果。
- 查看是否有任何解决能够应用 COMMIT NOWAIT 选项（但在应用之前肯定要理解它的语义）。
- 查看是否能够应用 NOLOGGING / UNRECOVERABLE 选项平安地实现任意操作。
- 查看重做日志是否足够大。增大重做日志，使日志在 15 到 20 分钟之间切换。
另外，日志文件同步期待的总工夫能够细分为以下几种：
- 闲暇时唤醒 LGWR
- LGWR 收集要写入的 redo 操作并收回 I / O 申请
- 日志写 I / O 实现工夫
- LGWR I/ O 开始工作
- LGWR 告诉写入实现的前台 / 用户会话
- 前台 / 用户会话唤醒