log file sync
当一个会话发出一个commit命令时，LGWR进程会将这个事务产生的redo log从log buffer里面写到磁盘上，以确保用户提交的信息被安全地记录到数据库中。
会话发出的commit指令后，需要等待LGWR将这个事务产生的redo 成功写入到磁盘之后，才可以继续进行后续的操作，这个等待事件就叫作log file sync。
_use_adaptive_log_file_sync 自适应切换
log file sync等待次数基本和数据库事务数持平。所以，log file sync等待是无法避免，但高事务量的系统容易引起大量的log file sync的等待事件。
优化方式:保证存储的写入性能，尽可能使用批量提交。
平均等待时间不应高于7ms,如果明显大于log file parallelwrite，则可能遭遇Bug
问题概述
（1）AWR显示超高的log file sync平均等待时间
（2）与log file sync平均等待时间相比，db file sequential read和log file parallel write平均等待时间都不高，可以排除IO本身的问题
adaptive_log_file_sync（3）lgwr.trc显示lgwr进程在post/wait和Polling（轮询）之间的自适应切换
*** 2020-04-13 17:05:05.806
Warning: log write broadcast wait time 1363604ms (SCN 0xf14.c25e76c0)
kcrfw_update_adaptive_sync_mode: post->poll long#=11 sync#=78 sync=14420 poll=8870 rw=4435 rw+=4435 ack=0 min_sleep=1288
*** 2020-04-23 16:06:04.271
Log file sync switching to polling ----->切换为polling模式
Current scheduling delay is 1 usec
Current approximate redo synch write rate is 26 per sec
*** 2020-04-23 16:07:39.409
kcrfw_update_adaptive_sync_mode: poll->post current_sched_delay=0 switch_sched_delay=1 current_sync_count_delta=34 switch_sync_count_delta=78
*** 2020-04-23 16:07:39.409
Log file sync switching to post/wait ----->切换为post/wait模式
Current approximate redo synch write rate is 11 per sec
*** 2020-04-23 16:45:03.911
Warning: log write elapsed time 500ms, size 1KB
*** 2020-04-26 19:06:46.530
Warning: log write elapsed time 53870ms, size 1KB(4)_use_adaptive_log_file_syn参数为TRUE
SQL> select x.ksppinm name, y.ksppstvl value, x.ksppdesc description
2 from sys.x$ksppi x, sys.x$ksppcv y
3 where x.inst_id = userenv('Instance')
4 and y.inst_id = userenv('Instance')
5 and x.indx = y.indx
6 and x.ksppinm like '_use_adaptive_log_file_sync%';
NAME VALUE DESCRIPTION
---------------------------------------- ---------- ----------------------------------------------------------------------
_use_adaptive_log_file_sync TRUE Adaptively switch between post/wait and polling问题原因
11gR2中引入了参数“_use_adaptive_log_file_sync”，并控制是否启用了post/wait和Polling之间的自适应切换。
在11.2.0.1和11.2.0.2中，参数的默认值为false。默认值从11.2.0.3开始更改为true。
为了确认提交已经完成，LGWR和前台进程可以通过两种方法进行通信:
（1）Post/wait——以前的Oracle版本中的传统方法
LGWR显式地发布所有等待提交完成的进程。
post/wait方法的优点是，当重做被刷新到磁盘时，会话应该立即发现。
（2）Polling
前台进程休眠并轮询，以查看提交是否完成。
这个新方法的优点是使LGWR不必通知许多等待提交完成的进程，从而释放了LGWR的高CPU使用率。
最初，LGWR使用post/wait，并根据内部算法评估polling是否更好。在高系统负载下，polling可能表现得更好，因为post/wait实现通常伸缩性不好。如果系统负载很低，那么post/wait执行得很好，并且提供了比polling更好的响应时间。Oracle依靠内部统计信息来决定应该使用哪种方法。因为在post/wait和轮询之间进行切换会增加开销，所以需要设置安全防护，以确保切换不会过于频繁。
解决方案
最佳实践建议关闭该特性，否则可能产生log file sync等待过高的问题。
将_use_adaptive_log_file_sync参数修改为false，该参数可以动态修改。
SQL> alter system set “_use_adaptive_log_file_sync”=false;
参考文档
Adaptive Log File Sync Optimization (Doc ID 1541136.1)
Adaptive Switching Between Log Write Methods can Cause ‘log file sync’ Waits (Doc ID 1462942.1)
