log file sync等待事件

概念：
1、REDO组件：
redolog buffer=>位于SGA中，是一块循环使用的内存区域，保存数据库变更的相关信息并以重做条目redoentries形式存储,包含DML及DDL语句;
LGWR=>通过此进程把redo buffer的内容写到redo log file中;
redo log file=>(在归档模式下被ARC n最终写入归档日志)。最少两组重做日志，每组最少一个成员默认三组REDO,保存从redo buffer写进的日志条目。
2、redo log file
当一组日志写满，会切换到另一组日志文件，称为log switch。此时会触发一个检查点，称为checkpoint scn，会促使DBWR将变更数据（即此checkpoint scn之前的脏数据dirty buffer）从buffer cache写回到数据库。检查点完成后，检查点前修改过的数据已经写回磁盘，重做日志文件中相应重做记录对于实例恢复不再有用。redo日志文件在重用前必须写到归档日志文件或清空，归档日志在介质恢复时可以用来恢复数据库故障。
3、Redo的内容
ORACLE通过REDO实现提交，一方面是因为redo log file可以连续、顺序快速写出，另一方面也和REDO记录的简单内容有关。
改变向量change vector ，改变向量表示对数据库内某一个数据库所做一次变更，包含变更数据库版本号，事务操作代码，变更从属数据块地址以及更新后的数据；可以通过dump redo 文件，来查看具体的redo文件的具体结构。
4、REDO写的触发条件-即LGWR触发条件
3秒超时，LGWR处于空闲状态时，
REDO log buffer  三分之一满，或者redolog buffer具有1MB的脏数据。
缺省值log_io_size等于1/3log buffer 大小，即达到1/3时也刚好1M，会触发LGWR。LOG BUFFER设置为3M
用户提交：当一个事务提交时，在redo stream中将记录一个提交标志。在redo被写到磁盘之前，这个事务是不可恢复，所以事务返回成功标志给用户前，需要等待LGWR写完成，进程通知LGWR写，并以log file sync事件开始休眠。
5、Commit
提交完成，意味着ORACLE已经将此时间点之前的RREDO写入了重做日志文件，这个日志写完成后，ORACLE可以释放用户去执行其它任务。

redo write time - 从重做日志缓冲区向当前重做日志文件写入所用的总时间，以10毫秒为单位。
redo writes - LGWR 向重做日志文件写入的总次数。每次写入的块数=写入重做块数/redo writes。
log file parallel write - 完成I/O的用时。虽然重做记录是并行写入的，但在最后一个I/O写入到磁盘上之前，并行写入不会完成。
user commits - 用户提交的数量。在用户提交事务时，必须将所生成的、反映对数据库块更改的重做写入到磁盘。提交操作通常代表的是最接近用户事务率的内容。
user rollbacks - 用户手动发布 ROLLBACK 语句的次数或者用户事务处理出误的次数。


log file sync等待事件
当一个用户session commit，session的重做信息需要从内存刷新到磁盘重做日志文件，使其永久化。在提交时，用户session通知LGWR把log buffer中信息包括当前所有未被写入磁盘的redo信息和
本次session信息写入到磁盘中redo 文件中。当LGWR完成写操作后，会返回信息给当前session。当等待LGWR通知所有redo写到redo file过程时，用户就会等待log file sync。这个过程就相当于一次回声。

log file sync”等待的典型生命周期
single:
1、当user session 提交（commit）时，
2、user session会通过server进程通知LGWR进程将redo buffer中的信息写入到redo log file，
3、LGWR进程得到提示后，会产生物理写动作，
4、LGWR再通知user session 写操作已经完成，
5、user session 接收到LGWR的通知后提交操作才完成

RAC:
1. 用户会话发布提交或回退操作，然后开始等待 log file sync。
2. LGWR收集要写入重做日志文件的重做信息，并同时LGWR将COMMIT SCN同步/传播给其它节点LMS进程，LMS将commit SCN同步到本地SCN，然后返回完成信息，
3. LGWR等待将重做信息刷新到磁盘以及等待SCN被确认收到
4. 完成IO并从LMS收到SCN的确认信息，表示写入完成。LGWR然后通知前台进程继续。
5. 前台进程被唤醒，且log file sync等待结束。

从上面的生命周期来看，网络\CPU\IO\业务的繁忙程度导致此等待事件的出现

1、比较'log file sync'和'log file parallel write'的平均等待时间。
如果'log file sync'的时间消耗在'log file parallel write'上的比例高，
那么大部分的等待时间是由于IO(等待redo写入)。应该检查LGWR在IO方面的性能。作为一个经验法则，'log file parallel write'平均时间超过20毫秒, 意味着IO子系统有问题。
Foreground Wait Events          DB/Inst: QUERYDB/querydb2  Snaps: 10031-10032
-> s  - second, ms - millisecond -    1000th of a second
-> Only events with Total Wait Time (s) >= .001 are shown
-> ordered by wait time desc, waits desc (idle events last)
-> %Timeouts: value of 0 indicates value was < .5%.  Value of null is truly 0
                                                             Avg
                                        %Time Total Wait    wait    Waits   % DB
Event                             Waits -outs   Time (s)    (ms)     /txn   time
------------------------------ ------------ ----------- ------ ------ ----------
log file sync                     2,237,887   375,999    168     66.14 Commit

Background Wait Events          DB/Inst: QUERYDB/querydb2  Snaps: 10031-10032
-> ordered by wait time desc, waits desc (idle events last)
-> Only events with Total Wait Time (s) >= .001 are shown
-> %Timeouts: value of 0 indicates value was < .5%.  Value of null is truly 0
                                                             Avg
                                        %Time Total Wait    wait    Waits   % bg
Event                             Waits -outs   Time (s)    (ms)     /txn   time
log file parallel write           1,075,038 0     1,010       98     0.30 13.09   
上面的例子显示了'log file sync' 和 'log file parallel write' 都有很高的等待时间
如果'log file sync'的时间消耗在'log file parallel write'上的比例高，那么大部分的等待时间是由于IO（等待redo写入）。
应该检查LGWR在IO方面的性能。作为一个经验法则，'log file parallel write'平均时间超过20毫秒, 意味着IO子系统有问题。

可通过下面来证明，
SQL> set timing on
SQL> alter database add logfile group  20 size 1024m;
Database altered.
Elapsed: 00:03:09.23==>5.4MB/s

建议
不要把重做日志放在RAID5
不要把重做日志放在SSD盘上，SSD写入性能好于平均水平，他们可能会遇到写峰值,从而导致大量的增加'log file sync'等待
监控其他可能需要写到相同路径的进程，确保该磁盘具有足够的带宽，足以应付所要求的容量。如果不能满足,移动这些进程或redo。
确保LOG_BUFFER不要太大，一个非常大的log buffer的不利影响就是刷新需要更长的等待时间。
当缓冲区满了的时候，它必须将所有数据写入到重做日志文件。LGWR将一直等待,直到最后的I/O完成。

2、检查 LGWR trace
尽管'log file parallel write'的平均等待时间可能在一个合理的区间范围内，在峰值时刻写操作时间还是可能会很长进而影响’log file sync’的等待时间。从10.2.0.4 开始如果写操作超过 500
毫秒我们会在 LGWR 的 trace 中写警告信息。这个阀值很高所以就算没有警告也不代表没有问题

注意：上面的峰值如果时间间隔的很远,可能不会对'log file parallel wait'有大的影响。 但是，如果有 100 个会话等待'log file parallel wait'完成，'log file sync'总等待可能就会很高，
因为等待时间将被乘以会话的个数 100。因此，值得探讨日志写 IO 高峰的原因

3、检查在线重做日志是否足够大
每次重做日志切换到下一个日志时，会执行'log file sync'操作，以确保下一个日志开始之前信息都写完。 标准建议是日志切换最多 15 至 20 分钟一次。 如果切换比这更频繁，
那么将发生更多的'log file sync'操作，意味着更多的会话等待。
Top 5 Timed Foreground Events
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                                           Avg
                                                          wait   % DB
Event                                 Waits     Time(s)   (ms)   time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
log file sync                     10,893,135   157,649      14  41.17   Commit
DB CPU                                         114,497           29.90   
log file switch (checkpoint incomplete) 11,232 48,463       4315 12.65 Configuration

Statistic                                     Total  per Hour
-------------------------------- ------------------ ---------
log switches (derived)                         1,207     86.30
在上面的例子中基于 AWR 中的信息，每小时有86.30次重做日志切换：每分钟切换1.4次。这个比每 15-20
分钟切换一次的建议值要高,并将影响前台进程需要等待'log file sync'完成的时间，因为发起同步操作的开销比必要的多
建议
增加redo logs的大小


3、应用程序提交过多
过多的commit活动可能会导致性能问题，因为把redo从日志缓冲区刷新到重做日志可能会导致等待'log file sync'。
如果’log file sync’的平均等待时间比’log file parallel write’高很多，这意味着大部分时间等待不是由于等待redo的写入，因而问题的原因不是IO慢导致。
剩余时间是CPU活动，而且是过多的commit导致的最常见的竞争。
此外，如果'log file sync'的平均等待时间低，但等待次数高，那么应用程序可能commit过于频繁。

user calls 53,459,673 29,381.29 14.86
user commits 2,171,336 1,193.36 0.60
user rollbacks 1,425,292 783.34 0.40

比较user commit/rollback同user calls比值的平均值
在AWR或Statspack报告中，如果每次commit/rollback的平均user calls（"user calls/(user commits+user rollbacks)"小于30，表明commit过于频繁

建议
如果有很多短事务，看是否可能把这些事务组合在一起，从而减少commit操作。 因为每一个commit都必须收到相关REDO已写到磁盘上的确认，额外的commit会显著的增加开销。
虽然 Oracle 可以将某些commit组合在一起，通过事务的批处理来减少commit的总体数量还是可以带来非常有益的效果。
看看是否有操作可以使用COMMIT NOWAIT 选项（务必在使用前应明白语义）。
看看是否有操作可以安全地使用NOLOGGING/ UNRECOVERABLE选项完成。

4、其他可能相关的等待事件
检查 AWR 报告，看是否有跟 LGWR 相关的,显示占用了显著数量时间的其他事件,因为这可能会给出导致这个问题的一个线索。前台和后台事件都应该进行检查。
例如下面的 AWR 显示某些其他前台和后台等待事件等待高，意味着传输重做日志到远程位置的问题，这可能会导致 fore gorund 进程等待"log file sync"。

5、Adaptive Log File Sync
11.2 中引入了 Adaptive Log File sync，由参数 _use_adaptive_log_file_sync 控制，在 11.2.0.1 和 11.2.0.2 默认设置为 false。
从 11.2.0.3 开始默认是 true。 当启用时，Oracle 可以在两种方法之间切换：
Post/wait，传统发布写重做日志完成的方法
Polling，一种新的方法，其中前台进程会检查 LGWR 是否已写完成。

6、也可通过下面的脚本来确诊log file sync的信息
Script to Collect Log File Sync Diagnostic Information (lfsdiag.sql) [Document 1064487.1]