log file sync P1 P2 P3

“log file sync”有三个参数：

P1 = buffer#

P2 = 未使用

P3 = 未使用

buffer#

这个buffer编号(在日志缓冲区中)的所有改变必须刷新到磁盘，写操作的完成保证了交易COMMIT的执行，即使实例crash也会保证COMMIT。因此LGWR的等待就是刷新这个buffer#。

等待时间：

这种等待完全依赖于LGWR写出所有必要的redo块，确保完成后返回给用户session。等待时间包括了日志缓冲写操作和提交操作。等待的时候，每秒都会增加序列号。

查找阻塞的块：

如果一个session持续等待同一个buffer#，那么SEQ#列应该每秒都会增加。否则本地session会出现等待事件超时的问题。如果SEQ#列持续增长，那么阻塞进程就是LGWR进程。检查LGWR正在等待哪些日志块的完成因而速度缓慢。

系统级等待：

系统级”log file sync“的等待参数显示了等待COMMIT完成花费的时间。如果这种等待非常明显，那么LGWR快速完整地刷出redo的能力就会有问题。”user commits“统计数据显示COMMIT的次数。

降低等待时间：

为了降低“log file sync”的等待，有几种常用调优的技巧：

>调优LGWR以能满足刷新到磁盘的良好性能，例如不用将redo日志存储到RAID5。

>如果有许多短时间的交易，看看是否可以进行批量交易，这样可以有更少的COMMIT操作。每次COMMIT都需要确认相关的redo信息是否刷新到磁盘。尽管commit是由Oracle内部处理的，但是通过批量交易可以降低commit的总体次数，达到一个非常好的效果。

>是否处理能够使用COMMIT NOWAIT选项(但在使用前需要理解他的语意)。

>确认任何交易使用NOLOGGING/UNRECOVERABLE选项是否安全。

>确认redo日志是否足够大。扩大redo日志，以保证日志切换可以控制在15到20分钟之间。

对于降低LOG FILE SYNC等待时间更加详细的分析可以参考如下：

LOG FILE SYNC等待的总时间可能会被切分为若干子节或组件。

如果确保上面提到的一些调优技巧已经使用了但你的系统仍旧显示较高的“log file sync”等待时间，那么你应该将总等待时间切分为单个的组件，然后调优这些组件，组成一个最长用时。

log file sync等待可能被切分为以下组件：

1. 唤醒已停止工作的LGWR。

2. LGWR收集需要写入磁盘与返回的IO。

3. 日志写IO完成的时间。

4. LGWR提交处理IO。

5. 写操作完成后LGWR提交给前台/用户session。

6. 唤醒前台/用户session。

基于log file sync切分后的组件的一些调优建议：

2和3累积在"redo write time"统计信息中。(例如Statspack和AWR的统计信息节中)

3是“log file parallel write”等待事件。

5和6随着系统负载的增加可能变得非常明显。这是因为即使已经返回请求到前台进程，仍可能需要花费OS时间进行调度执行。需要从操作系统级别的监控。

Data Guard的观点：

对于Data Guard，具有异步传输与默认的COMMIT WAIT功能，以上的调优步骤仍可以使用，除了第三步也包括对于备机redo日志的网络写与RFS/redo写的用时