log file sync（ 日志文件同步）等待事件

log file sync等待事件发生

log file sync等待事件发生在redo log从log buffer写入到log file期间。
在一个提交（commit）十分频繁的数据库中，一般会出现log file sync等待事件，当这个等待事件出现在top5中，这个时侯我们需要针对log file sync等待事件进行优化，一定要尽快分析并解决问题，否则当log file sync等待时间从几毫秒直接到20几毫秒可能导致系统性能急剧下降，甚至会导致短暂的挂起。

何时发生日志写入

1.commit或者rollback
2.每3秒
3.log buffer的1/3满或者已经有1M的redo数据。
更精确的解释：参数_LOG_IO_SIZE大小默认是LOG_BUFFER的1/3，当log buffer中redo数据达到_LOG_IO_SIZE大小时，发生日志写入。
4.DBWR写之前

_log_io_size隐含参数

LOG_BUFFER（bytes）写入的数量超过_LOG_IO_SIZE会触发LGWR写日志的条件,缺省值为LOG BUFFER的1/3或1M。
但是这个说法通过查询并不能验证，隐含参数尽量不要修改。

SQL> col name for a25
SQL> col VALUE for a20
SQL> col DESCRIB for a50
SQL> SELECT x.ksppinm NAME, y.ksppstvl VALUE, x.ksppdesc describ
FROM SYS.x$ksppi x, SYS.x$ksppcv y
WHERE x.inst_id = USERENV ('Instance')
AND y.inst_id = USERENV ('Instance')
AND x.indx = y.indx
AND x.ksppinm LIKE '_log_io_size';

NAME                 VALUE                DESCRIB
-------------------- -------------------- --------------------------------------------------
_log_io_size         0                    automatically initiate log write if this many redo                                           blocks in buffer                                       

如何查看oracle隐含参数

log file sync发生的过程

此等待事件用户发出提交或回滚声明后，等待提交完成的事件，提交命令会去做日志同步，也就是写日志缓存到日志文件，在提交命令未完成前，用户将会看见此等待事件。
注意，它专指因提交,回滚而造成的写缓存到日志文件的等待。当发生此等待事件时，有时也会伴随log file parallel write。因为此等待事件将会写日志缓存，如果日志的I/O系统较为缓慢的话，这必将造成log file parallel write 等待。当发生log file sync等待后，判断是否由于缓慢的日志I/O造成的，可以查看两个等待事件的等待时间，如果比较接近，就证明日志I/O比较缓慢或重做日志过多。这时，造成log file sync的原因是因为log file parallel write，可以参考解决log file parallel write的方法解决问题。

log file parallel write

log file parallel write是发生在LGWR将重做记录从重做日志缓冲区复制到当前在线日志中。它是一个后台等待事件（log file sync是一个前台等待事件），通常与IO不佳相关，它是log file sync事件的一个子过程。

该等待事件共有3个参数：

SQL> select PARAMETER1,PARAMETER2,PARAMETER3 from v$event_name where name='log file parallel write';
PARAMETER1 PARAMETER2 PARAMETER3
---------- ---------- ----------
files      blocks     requests

• files:写入的文件数。如果每个组有多个日志成员，则文件将并行写入。
• blocks:要写入的块数。写入每个日志成员的REDO块数。
• requests：I/O请求数。不同IO请求的数量。要写入的块数被划分为多个IO请求。

log file sync的各个环节

引用一下tanel poder大师画的的延迟图

The log file sync wait may be broken down into the following components:
1.user session（用户进程） 发起commit

• Wakeup LGWR if idle 唤醒LGWR进程

2.前台程序通知LGWR进程将redo buffer中的信息写入到redo log file

3.LGWR接收到请求并发出物理写的系统调用

• LGWR gathers the redo to be written and issue the I/O LGWR进程收集redo，然后发给I/O
• Time for the log write I/O to complete 等待log写入I/O

4.物理写的系统调用完成

5.LGWR再post（通知）FG proc（前台程序）写操作已经完成

• LGWR I/O post processing
• LGWR posting the foreground/user session that the write has completed LGWR通知前台/用户回话，redo写入完成

6.user session 接收到LGWR的通知后提交操作才完成*

• Foreground/user session wakeup 前台/用户会话唤醒

因此user session 在没有收到LGWR post（通知）之前一致处于等待状态，具体的等待事件为log file sync。

步骤3消耗的时间在AWR中的"redo write time"中有所体现。(AWR中 Instance Activity Stats )
其中，步骤“Time for the log write I/O to complete”产生"log file parallel write"等待事件。(Document:34583.1 “log file parallel write” Reference Note)
另外：如果是最大保护模式的DATAGUARD(SYNC传输),这一步骤还包含网络写、RFS/redo写入到备库的standby log file sync的时间。

Steps 5 and 6 may become very significant as the system load increases. This is because even after the foreground has been posted it may take a some time for the OS to schedule it to run. May require monitoring from O/S level.
在系统负载高时（尤其是CPU高的情况，看vmstat r值），步骤5和6会变得非常明显。因为，前台收到LGWR写入完成的通知后，操作系统需要消耗一些时间调度Foreground/user session进程唤醒（也就是CPU调度）。需要系统级别监控。

1,2阶段的时间，主要是post/wait的时间，典型的这种post/wait一般利用的是操作系统的信号量（IPC)实现，如果系统CPU资源充足，一般不会出现大的延迟。前台进程post lgwr后，就开始等待log file sync。

2,3阶段的时间，主要是lgwr为了获取cpu资源，等待cpu调度的时间，如果系统cpu资源充足，一般不会出现大的延迟。这里我们需要知道，lgwr只是操作系统的一个进程，它需要操作系统的调度获取cpu资源后才可以工作

3,4阶段的时间，主要是真正的物理io时间，lgwr通知os把log buffer的内容写入到磁盘，然后lgwr进入睡眠（等待log file parallel write），这个时间正常情况下的延迟占整个log file sync的大部分时间。还需要指出，lgwr在获取cpu资源后，可能并不能马上通知os写磁盘，只有在确保所有的redo copy latch都已经被释放，才能开始真正的IO操作。

4,5阶段的时间，os调度lgwr 重新获得cpu资源，lgwr post前台进程写完成。lgwr可能会post很多前台进程(group commit的副作用)

5,6阶段的时间，前台进程接受到lgwr的通知，返回cpu运行队列，处理其他事物（log file sync结束）。

• 总结：
  如果log file sync的等待时间很高,而log file parallel write的等待时间并不高,这意味着log file sync的原因并不是缓慢的日志I/O,而是应用程序过多的提交造成。
  当log file sync的等待时间和 log file parallel write等待时间基本相同，说明是IO问题造成的log file sync等待事件。

引起log file sync的原因

1. 频繁提交或者rollback,检查应用是否有过多的短小的事务，如果有，可以使用批处理来缓解。
2. OS的IO缓慢：解决办法是将日志文件放裸设备上或绑定在RAID 0或RAID 1+0中，而不是绑定在RAID 5中。
3. 过大的日志缓冲区（log_buffer ）
   过大的log_buffer,允许LGWR变得懒惰，因为log buffer中的数据量无法达不到_LOG_IO_SIZE，导致更多的重做条目堆积在日志缓冲区中。
   当事务提交或者3s醒来时，LGWR才会把所有数据都写入到redo log file中。
   由于数据很多，LGWR要用更多时间等待redo写完毕。
   这种情况，可以调小参数_LOG_IO_SIZE参数，其默认值是LOG_BUFFER的1/3或1MB，取两者之中较小的值。
   换句话说，你可以具有较大的日志缓冲区，但较小的_LOG_IO_SIZE将增加后台写入次数，从而减少log file sync的等待时间。
4. CPU负载高。
5. RAC私有网络性能差，导致LMS同步commit SCN慢。

如何诊断log file sync

1. AWR：发生log file sync时，先做个snapshot，然后做AWR，AWR时间选择在10-30分钟。
   已发生的log file sync，那么通过AWR依然可以分析，也要保持在10-30分钟。
2. LGWR trace file（10.2.0.4开始），大于500ms会写入
   trace文件中如果有Warning: log write time 1000ms, size 2KB，很有可能IO慢。
   
3. 分析CPU资源使用情况的工具，CPU过于繁忙，lgwr无法及时获取CPU调度，出现log file sync。
   vmstat，关注r是否大于CPU核数，大于说明cpu繁忙。
   OSW:OSWatcher,同上。
4. Alert：确认log file 15到20分钟切换一次
5. Script to Collect Log File Sync Diagnostic Information (lfsdiag.sql) [Document 1064487.1]

解决办法

1. 优化了redo日志的I/O性能，尽量使用快速磁盘，不要把redo log file存放在raid 5的磁盘上；
2. 加大日志缓冲区(log buffer)；
3. 使用批量提交，减少提交的次数；
4. 部分经常提交的事务设置为异步提交；
5. 适当使用NOLOGGING/UNRECOVERABLE等选项；会减少redo产生量
6. 采用专用网络，正确设置网络UDP buffer参数；

常用的 log file sync等待时间的优化手段

1. log file sync平均等待事件时间超过7ms，如果等待时间过长，说明log write每次写入的时间过长，如果能够优化redo日志文件存储，使之存放在更快的磁盘上，就可以减少这个等待事件的单次等待时间。（RAID 5–> RAID 10）
   　当无法通过优化redo日志的I/O性能来解决问题，或者优化了redo日志的I/O性能后还是无法达到我们的预期，那么该如何处理呢？

2. 有经验的DBA可能会建议加大日志缓冲区（log buffer）。提到加大日志缓冲区，可能有些朋友就会感到疑惑，redo日志文件写等待时间长怎么会和日志缓存冲区直接关联起来呢？实际上这个问题解释起来一点也不难，如果数据文件的I/O性能有问题，平均单块读的等待时间偏长，那么通过加大db cache来减少I/O总次数，从而达到优化I/O的效果。加大日志缓存区的原理也是一样的，这样可以使日志缓存中的存储更多的redo日志数据，从而减少由于redo日志缓存区不足而产生lgwr写操作的数量，使平均每次写入redo日志文件的redo字节数增加，从而减少redo的I/O次数，进而达到优化log file sync等待事件的目的。

3. 如果上述两种方法都不行时，还有一种方法：就是减少提交的次数。如果提交过于频繁，那么无论怎么优化都无法彻底解决问题。
   　通过加大一次提交记录的数量，减少提交批次，可以有效地减少log file sync等待时间。采用此方法就意味着需要对应进行较大的调整，甚至要对应用架构做出修改，这种修改的代价将十分巨大。

4. 还有一个方案可以优化log file sync事件，就是把部分经常提交的事务设置为异步提交。
   　　异步提交是10g版本引入的新特性，通过设置commit_write参数，可以控制异步提交。
   　　commit_write参数默认值是“immediate,wait”可以设置为“immediate,nowait”来实现异步提交。
   采用异步提交的系统需要做一些额外的校验和处理，清理不一致的数据，重新插入刚才由于异步提交而丢失的数据。这就需要在应用层面进行一些特殊处理，建校验机制和错误数据处理机制。我们需要在应用层面进行一些特殊的设置。应该注意的是，那些特别重要的，后续无法重新完全补充的数据不适合使用这种方法

几个技术指标

log file sync 等待时间小于20ms算正常
log file parallel write 等待时间小于20ms算正常
log file parallel wirte 和log file sync等待时间很接近，说明就是IO问题，因为大部分时间都花在了log写入到磁盘上。

相关脚本

• 等待时间平均等待时间

SQL> select EVENT,TOTAL_WAITS,TOTAL_TIMEOUTS,TIME_WAITED,AVERAGE_WAIT
from   v$system_event 
where  event in ('log file sync','log file parallel write'); 

SQL> select value from v$parameter where name = 'log_buffer';

获取log file sync、log file parallel write时间分布

如果我们仅仅观察AWR报告，获取log file sync、log file parallel write某一段时间的平均等待时间，有时候是不够的，我们可能想更精细化的知道，10000次等待里，有多少次等待是在1ms以内，有多少次是在2ms以内，等等。查询V$EVENT_HISTOGRAM可以告诉我们这些信息，对于我们诊断性能问题非常有帮助。

SQL> select event, wait_time_milli,wait_count
from v$event_histogram
where event = 'log file parallel write';

SQL>select event, wait_time_milli,wait_count
from v$event_histogram
where event = 'log file sync';

新特性：log file sync 两种方式

Adaptive Log File Sync
Adaptive Log File sync was introduced in 11.2. The parameter controlling this feature, _use_adaptive_log_file_sync, is set to false by default in 11.2.0.1 and 11.2.0.2.

_use_adaptive_log_file_sync参数在11gR2提出。11.2.0.1和11.2.0.2两个版本该参数默认是false。
从11.2.0.3开始，这个参数默认值是true，也就是开始启用“自适应日志同步机制”。

11.2.0.1和11.2.0.2也可以开启改参数

ALTER SYSTEM SET "_use_adaptive_log_file_sync"=  scope=;

开启该参数后，日志同步机制会在2种方式中切换。
该参数决定了，foreground/user session 和LGWR进程通过什么方式获知commit操作已完成（也就是redo写log file完成）。

• post/wait
  Post/wait, traditional method for posting completion of writes to redo log
  传统方式，在11.2.0.3之前，user session等待LGWR通知redo写入到log file完毕，被动方式。
  优点：post/wait方式，user session几乎能立即发现redo已刷到磁盘。
• polling
  Polling, a new method where the foreground process checks if the LGWR has completed the write.
  新方式，主动监测LGWR是否完成写入，主动方式。这种方式比Post/wait方式响应速度慢，但是可以节约CPU资源。
  优点：当commit完成后，LGWR会把commit完成的消息通知给很多user session，这个过程消耗大量CPU。
  Polling方式采用朱勇监测LGWR释放写入redo完成，所以释放了LGWR占用的CPU资源。
• 如何选择
  系统负载高（CPU繁忙）采用Polling方式更好。
  系统负载低（CPU清闲）采用post/wait方式更好，它能够提供比polling方式更好的响应时间。
  ORACLE根据内部统计信息决定采用何种方式。post/wait和polling方式互相切换能引起过热，为了确保安全，切换不要太频繁。
• 查询当前log file sync 方式是post-wait还是poll
  1.LGWR的trace文件记录了switch记录，关键字是 “Log file sync switching to …”:
  2.相关脚本：
  查询当前log file sync 方式是post-wait还是poll

SQL> select name,value from v$sysstat where name in ('redo sync poll writes','redo synch polls');
NAME                                    VALUE
--------------------------------------- ----------
redo synch polls                        325355850

• 每小时采用poll log file sync方式的次数

SQL> col begin_interval_time format a25
SQL> col instance_number format 99 heading INST
SQL> col stat_name format a25
SQL> select snap.BEGIN_INTERVAL_TIME,hist.instance_number , hist.stat_name,hist.redo_synch_polls
from ( select snap_id,instance_number,stat_name,value -lag(value,1,null) over ( order by snap_id,instance_number,stat_name) redo_synch_polls
        from dba_hist_sysstat
        where stat_name='redo synch polls'
        and dbid=(select dbid from v$database)
        and instance_number = nvl('&instance_number',1)) hist,
        dba_hist_snapshot snap
where redo_synch_polls >0
and hist.snap_id=snap.snap_id
and hist.instance_number=snap.instance_number
order by 1,2
/

---

参考：

由哪些会话导致的log file sync等待
魏兴华大师在itpub上的一篇帖子
log file sync 等侍值高的一般通用解决办法
完全揭秘log file sync