在一个频繁 commit/rollback 或磁盘 I/O 有问题、大量物理读写争用，那么、我们便会经常瞧见 LOG FILE SYNC 等待事件出现在 TOP
在一个频繁 commit/rollback 或磁盘 I/O 有问题、大量物理读写争用，那么、我们便会经常瞧见 LOG FILE SYNC 等待事件出现在 TOP EVENTS 中，评估 LOG FILE SYNC等待事件的指标是平均等待时间、以及 AWR 后续的 WAIT EVENT HISTOGRAM
对于 OLTP、平均等待时间 7 ms算正常、正常情况下平均等待时间不会超过 10 ms
下面给出几种优化的策略、
㈠ 优化 REDO 日志的 I/O
如果能够优化 REDO 日志文件的存储、使之存放到更快的磁盘、便可减少这个等待事件单次等待时间
㈡ 加大 LOG BUFFER
加大 LOG BUFFER 、可使平均每次写入 REDO 日志文件的 REDO 字节数增加。
从而、减少 REDO 的 I/O 次数、进而达到优化 REDO 日志文件写等待时间的目的
㈢ 减少提交次数
通过加大一次提交记录的数量、减少提交批次、也可有效减少 LOG FILE SYNC等待时间
不过、此法可能需要变更应用、代价较大
㈣ 部分经常提交的事务设置为异步提交
通过设置 COMMIT_WRITE参数、可以控制异步提交该参数支持系统级、但也支持会话级
其中、"IMMEDIATE,NOWAIT"是较为常用的优化方案可通过：
● 变更参数 commit_write
● 直接命令：commit write immediate nowait
最后、Rocky 想在唠叨 3 下、我们在数据库的日常维护中应该对此建立基线(baseline)
如果这个指标有异常变化、一定要尽快分析并解决问题、一旦这个指标恶化，，可能导致系统性能急剧下降、甚至会导致短暂的挂起。
