关于css3:log-file-sync日志等待

55次阅读

共计 1365 个字符，预计需要花费 4 分钟才能阅读完成。

当用户会话（前台过程）提交（或回滚）时，会话的 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 分钟之间切换。

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