记一次生产数据库log file sync 等待事件异常及处理过程

(RAID 5不对数据进行备份，而是把数据和与其相对应的奇偶校验信息存储到组成RAID5的各个磁盘上，并且奇偶校验信息和相对应的数据分别存储于不同的磁盘上。当RAID5的一个磁盘数据损坏后，利用剩下的数据和相应的奇偶校验信息去恢复被损坏的数据。)

5. 计算平均日志写大小：

avg.redo write size = (Redo block written/redo writes)*512 bytes= ( 3,596,472/ 150,976 )*512 =12196 bytes =11KB 

这个平均值有点小了，说明系统的提交过于频繁。

从以上的统计信息中， 可以看到平均每秒数据库的提交数量是18.62 次。 如果可能， 在设计应用时应该选择合适的提交批量，从而提高数据库的效率。

6. Oracle11g新特性(Adaptive Log File Sync - 自适应的Log File Sync)

关于 Log File Sync 等待的优化，在Oracle数据库中一直是常见问题，LOG FILE的写出性能一旦出现波动，该等待就可能十分突出。

在Oracle 11.2.0.3 版本中，Oracle 将隐含参数 _use_adaptive_log_file_sync 的初始值设置为 TRUE，由此带来了很多 Log File Sync 等待异常的情况，当前台进程提交事务(commit)后，LGWR需要执行日志写出操作，而前台进程因此进入 Log File Sync 等待周期。

在以前版本中，LGWR 执行写入操作完成后，会通知前台进程，这也就是 Post/Wait 模式;在11gR2 中，为了优化这个过程，前台进程通知LGWR写之后，可以通过定时获取的方式来查询写出进度，这被称为 Poll 的模式，在11.2.0.3中，这个特性被默认开启。这个参数的含义是：数据库可以在自适应的在 post/wait 和 polling 模式间选择和切换。

_use_adaptive_log_file_sync 参数的解释就是： Adaptively switch between post/wait and polling ，正是由于这个原因，带来了很多Bug，反而使得 Log File Sync 的等待异常的高，在遇到问题时，通常将 _use_adaptive_log_file_sync 参数设置为 False，回归以前的模式，将会有助于问题的解决。

这里我的数据库版本是11.2.0.1，检查发现也有这种情况，所以做了一些参数上的调整：

SQL> show parameter parallel_adaptive_multi_user; 
SQL> alter system set parallel_adaptive_multi_user=false scope=both; 

【编辑推荐】

1. 关于Oracle数据库Kfk: Async Disk IO等待事件深度解析
2. 9月数据库排行：Microsoft SQL Server 分数罕见下滑
3. 分享一次生产MySQL数据库主备切换演练
4. 详解MySQL数据库常见的索引问题：无索引，隐式转换，附实例说明
5. 闲聊数据库高可用容灾规划设计

（编辑：常州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!