log file sync(日志文件同步) 与 Log file parallel write 等待事件

log file sync(日志文件同步) 与 Log file parallel write 等待事件

log file sync(日志文件同步)等待事件具有一个参数:buffer#。在Oracle Database 10g中，这种等待事件位于Commit等待下面。当处理log file sync等待事件时，注意下面的思想：

◎ log file sync 等待时间和事务中指(提交或回滚)相关

◎当进程在log file sync事件上花费大量时间时，这通常表明过多的提交或短事务。

触发LGWR进程的条件有：

1. 用户提交

2. 有1/3重做日志缓冲区未被写入磁盘

3. 有大于1M的重做日志缓冲区未被写入磁盘

4. 3秒超时

5. DBWR 需要写入的数据的SCN大于LGWR记录的SCN，DBWR 触发LGWR写入。

触发DBWR进程的条件有：

1. DBWR超时，大约3秒

2. 系统中没有多余的空缓冲区来存放数据

3. CKPT 进程触发DBWR

由用户提交和回滚初始化的写入称为同步写入；其余的写入成为后台写入。log file sync

等待只和同步写入有关。换句话说，用户进程可能正在处理一个大型的事务并生成许多触发LGWR以执行后台写入的大量重做条目，但用户会话从来不需要等待后台写入的完成。然而，一旦用户会话提交或回滚它的事务且

_WAIT_FOR_SYNC参数是TRUE时，进程提交LGWR并在log file sync事件上等待LGWR将当前重做条目(包括提交标记)刷新到日志文件。在这种日志同步期间，LGWR进程在log file parallel write事件上等待同步写入的完成，同时用户会话在log file sync事件上等待同步进程的完成。

一旦进程进入log file sync等待，就有两种可能性。

一种可能性是LGWR在日志同步完成时提交前台进程时。

另一种情况是在等待已超时的时候(一般在1秒内)，在这个时刻，前台进程检查当前日志SCN(System Change Number,系统改变号)，确定它的提交是否已经传递到磁盘。如果是的话，进程继续处理，否则进程就重新进入等待。

高log file sync等待事件的3个主要原因。

①．高提交频率

解决方法是简单的消除不必要的提交，事务是工作单元。工作单元应该是全部成功或全部失败。

②．缓慢的I/O子系统

较高的IO吞吐良可以改善log file sync和log file parallel write事件的平均等待时间。频繁的提交会弄乱数据库布局和IO子系统。解决办法是将日志文件放裸设备上或绑定在RAID 0或RAID 0+1中，而不是绑定在RAID 5中。

③．过大的日志缓冲区

过大的日志缓冲区也可能延长log file sync等待。大型的日志缓冲区减少后台写入的数量，允许LGWR变得懒惰，并导致更多的重做条目堆积在日志缓冲区中。同时可以调整参数_LOG_IO_SIZE参数，其默认值是LOG_BUFFER的1/3或1MB，取两者之中较小的值。换句话说，你可以具有较大的日志缓冲区，但较小的_LOG_IO_SIZE将增加后台写入，从而减少log file sync的等待时间。

注意：

你必须绝对不将参数_WAIT_FOR_SYNC设置为FALSE，即使是在一个开发数据库或测试数据库中，因为不能保证提交的事务在实例失败时可以恢复。人们使用这种特性来避开基准测试。

一般情况下，log file sync等待是非常频繁的时间。它非常简短，终端用户一般不会注意到它。然而，许多这样的事件可能产生较长的响应时间并在

v$system_event和v$session_wait

视图中获得显著的等待统计。使用下面的查询来找到当前的会话，这些会话从登陆开始就花费大量的处理时间在log file sync事件上等待。

L og file parallel write

log file parallel write事件是LGWR进程专属的等待事件，发生在LGWR将log_buffer中的重做日志信息写入联机重做日志文件组的成员文件，LGWR在该事件上等待该写入过程的完成。

该事件等待时间过长，说明日志文件所在磁盘缓慢或存在争用。

从两个方面入手解决：

（1）将日志文件组放置到高速I/O磁盘上。

（2）尽可能的降低重做数量：

—尽可能使用Nologging选项，包括create table...as select...操

作

—热备份可能创建大量的重做信息，所以热备份应该在非高峰时间运行，并且尽可能将表空间排除在热备份模式外

LGWR 是负责把Redo Log buffer写入Redo file的进程，当这个进程启动的时候，会把redo buffer里已经有的redo record写入redo file，而当用户commit 或者rollback的时候，会触发这个进程，从而保证用户的提交的数据安全，只有写入到redo file，才能保证这个操作是可以恢复的。

只有当某个事务所产生的重做记录全部被写入重做日志文件之后，oracle才认

为这个事务已经成功提交.重做记录也可能会在事务提交之前就写入重做日志文件.

LGWR进程在开始写入下一个重做日志文件之前，必须确认这个即将被覆盖的重

做日志文件已经完成如下工作：

* 如果数据库处于非归档模式,已写满的重做日志文件在被覆盖之前，其中所有重做记录所对应的事务的修改

操作结果必须已经全部被写入到数据文件中

* 如果数据库处于归档模式,已写满的重做日志文件在被覆盖之前，不仅要对应所有事务的修改操作结果全部被写入到数据文件中，还需要等待归档进程完成对它的归档操作

常见的原因、诊断和动作

Oracle 在SGA中的日志缓冲区中记录事务和块的改变，这是成为生理日志(physiological logging)的方法。通过以各种时间进度将内容写入到日志文件，LGWR进程负责在日志缓冲区中留出空间。

metalink上的解释：

"log file sync" Reference Note

When a user session(foreground process) COMMITs (or rolls back), the session's redo information needs to be flushed to the redo logfile. The user session will post the LGWR to write all redo required from the log buffer to the redo log file. When the LGWR has finished it will post the user session. The user session waits on this wait event while waiting for LGWR to post it back to confirm all redo changes are safely on disk.

This may be described further as the time user session/foreground process spends waiting for redo to be flushed to make the commit durable. Therefore, we may think of these waits as commit latency from the foreground process (or commit client generally).

See Reducing Waits section below for more detailed breakdown of this wait