今天主要从一个案例介绍logfilesync等待事件和一些常用的解决方法。我们先来看故障时间段内的等待事件。1.查看freeze时间段内的等待事件和session查看failure时间段内的等待事件，问题sqlid和session访问次数selecttrunc(sample_time,'mi')tm,sql_id,nvl(event,'CPU'),count(distinctsession_id)cntfromdba_hist_active_sess_historywheresample_timebetweento_date('2019-09-039:30:00')andto_date('2019-09-0311:00:00')groupbytrunc(sample_time,'mi'),sql_id,nvl(事件,'CPU')orderbycntdesc;查看sql相关的等待事件和对应的session访问次数selectsql_id,nvl(event,'CPU'),count(distinctsession_id)szfromdba_hist_active_sess_history,dba_hist_snapshotbwheresample_timebetweento_date('2019-09-0309:30:00')andto_date('2019-09-0311:00:00')andsql_id='0spj1q9t1yh2d'anda.snap_id=b.snap_idanda.instance_number=b.instance_numbergroupbysql_id,nvl(event,'CPU')orderbyszdesc;很明显是logfilesync等待事件。那么什么是日志文件同步呢？2.logfilesync——日志文件同步在一个commit非常频繁的数据库中，一般都会有一个logfilesync等待事件。当这个等待事件出现在top5的时候，这个时候我们需要优化logfilesync等待事件，一定要尽快分析解决问题，否则logfilesync等待时间直接从几毫秒到20毫秒可能导致系统性能急剧下降，甚至出现短时挂起。当用户提交或回滚数据时，LGWR将会话的重做从LogBuffer中写入重做日志，完成任务后LGWR会通知用户进程。日志文件同步等待（LogFileSync）表示进程等待LGWR写入完成。对于回滚操作，该事件记录了从用户发出回滚命令到回滚完成的时间。如果等待过多，可能说明LGWR的写入效率低下，或者系统提交过于频繁。对于这个问题，可以关注logfileparallelwritewaitingevent，或者通过usercommits、userrollback等统计信息观察commits或rollbacks的次数。简而言之，日志文件同步的根本原因一般是频繁的commit/rollback或者磁盘I/O问题，以及大量的物理读写争用。平均Redowritesize可以通过以下公式计算：avg.redowritesize=(Redoblockwritten/redowrites)*512bytes如果系统产生的Redo很多，每次写的比较少，一般说明LGWR激活过于频繁。可能会导致过多的Redo相关的Latch竞争，Oracle可能无法有效地使用piggyback功能。从AWR报告中提取一些数据来调查此问题。logfilesync等待事件优化方案：优化redologs的I/O性能，尽量使用快盘，不要将redolog文件存放在raid5盘；增加日志缓冲区（logbuffer）；使用批量提交，减少提交次数；一些频繁提交的事务设置为异步提交；适当使用NOLOGGING/UNRECOVERABLE和其他选项；使用专用网络，正确设置网络UDP缓冲参数；安装最新版本的数据库以避免bug3。awrreport--rmanbackupcollectionawrreport来分析，这里就不介绍收集过程了。(1)报告如下：这里可以注意到有一个异常的等待事件--RMANbackup&recoveryI/O，应该是rman刚做备份导致的busydiskIO引起的(2)观察RMAN日志明显是从早上5点开始备份，一直备份到接近10点，这也消耗了一部分磁盘IO（三）调整备份时间我们回到日志分析文件同步。4、awrreport--logfilesync注意上面的输出信息，这里logfilesync和dbfileparallelwrite等等待事件同时发生，那么一个可能的原因是I/O竞争导致性能问题，实际用户环境恰恰是日志文件和数据文件同时存放在RAID5磁盘上，存在性能问题需要调整。（RAID5不备份数据，而是在组成RAID5的每个磁盘上存储数据和对应的校验信息，校验信息和对应的数据存储在不同的磁盘上。当RAID5的其中一个磁盘数据损坏后，使用剩余的数据和相应的校验信息来恢复损坏的数据。）5.计算平均日志写入大小：avg.redowritesize=(Redoblockwritten/redowrites)*512bytes=(3,596,472/150,976)*512=12196bytes=11KB这个平均值有点小，说明系统提交过于频繁。从上面的统计可以看出，平均每秒数据库提交次数为18.62次。如果可能，在设计应用程序时应选择合适的提交批次，以提高数据库的效率。6、Oracle11g的新特性（AdaptiveLogFileSync——AdaptiveLogFileSync）关于LogFileSync等待的优化，一直是Oracle数据库的通病。一旦LOGFILE的写入性能出现波动，等待可能会非常突出。在Oracle11.2.0.3版本中，Oracle将隐式参数_use_adaptive_log_file_sync的初始值设置为TRUE，带来了很多LogFileSync等待异常。当前前台进程提交事务（commit）后，LGWR需要执行logWrite操作，前台进程由此进入LogFileSync等待周期。在之前的版本中，LGWR会在写操作完成后通知前台进程，即Post/Wait模式；在11gR2中，为了优化这个过程，前台进程通知LGWR写入，可以通过定时查询写入进度，称为Poll方式。在11.2.0.3中，此功能默认启用。该参数的含义是：数据库可以自适应地在post/wait和polling模式之间进行选择和切换。_use_adaptive_log_file_sync参数的解释是：Adaptivelyswitchbetweenpost/waitandpolling。也正是因为这个原因，带来了很多bug，导致LogFileSync的等待时间异常的高。遇到问题时，_use_adaptive_log_file_sync参数通常设置为False，回到之前的模式有助于解决问题。这里我的数据库版本是11.2.0.1，也是这样，所以我做了一些参数调整：SQL>showparallel_adaptive_multi_user;SQL>altersystemsetparallel_adaptive_multi_user=falsescope=both;
