等待事件之日志等待“log file parallel write”

jiawang

定义
当每个Redo日志组有两个及以上的member时，LGWR进程会把日志缓冲器中的redo记录并行写入到log file中，就会产生该等待事件，并且直到所有I/O操作完成了，该写操作才会完成。该等待事件是redo记录从重做日志缓冲区复制到当前联机日志的正常活动的一部分。

对于自身范围内产生的等待
1. 查看动态性能视图V$SESSION_WAIT涉及到的“log file parallel write”参数
P1 = files
P2 = blocks
P3 = requests
注：
files：写入的文件数。如果每个组有多个日志成员，则文件将并行写入，那么这就是写入的重做日志成员（文件）的数量。
Blocks：写入每个日志成员的REDO块数。比如：值为8表示每个日志成员有8个重做块。
requests：不同I/O请求的数量。要写入的块数会被分成若干个I/O请求。

2. 等待时间
实际等待时间是完成所有未完成的I/O请求所需的时间。 即使可以并行写入，LGWR也需要等待最后一个I/O出现在磁盘上，然后才认为并行写入完成。因此，等待时间取决于操作系统完成所有请求所需的时间。

对于系统范围内产生的等待
由于正常Oracle影子进程（shadow processes）不使用此等待，因此“系统范围”的数字不应直接包含在比较中。如果等待“log file parallel write”的时间很长，那么这将会显示为其他用户等待事件（例如较长的“log file sync”等待时间）。
如果用户等待表明LGWR不够快，那么此等待事件的数字以及一些与重做相关的统计数据可以帮助显示LGWR是否是受到了I/O响应时间很长的影响。
对于与 LGWR 写入性能直接相关的数据，可以查看下面几种方面的统计数据：
1） redo writes
2） redo blocks written
3） redo write time
4） redo wastage
5） redo size

减少等待和等待时间的方法
1. 确保表空间处于热备份（HOT BACKUP）模式的时间不会超过所需时间。因为热备份模式下的表空间会导致每次更改生成更多重做，这可以大大提高重做生成率。
2. 如果可以使用NOLOGGING / UNRECOVERABLE的操作可以降低重做日志生成的速率。
3. 重做日志成员最好放在速度很快的磁盘上。但是不要使用RAID5，最好使用裸设备。
4. 重做日志成员应该放在很少/没有来自其他来源的I/O活动的磁盘上。包括来自其他来源的针对同一磁盘控制器的部分少量的活动，比如存还放了归档文件。
5. 对于ASM和ZFS之类的文件系统，可能还必须试验磁盘条带大小。
6. 检查系统是否未受CPU（或内存）限制，否则LGWR可能需要更多时间来识别I/O是否已完成。
7. 如果使用了LogMiner，Logical Standby和Stream，如果能够满足现有的需求的功能，尽可能使用最低级别的追加日志来减少Redo日志的产生。
8. 尽可能将同一个日志组内的redo成员分散到不同的磁盘上，来减少并行写redo日志产生的I/O竞争。