想关注我吗？请点击图片上方��������,ʹ��ǰ��蓝字小麦苗关注即可，关注后您将可以每日获得最实用的数据库技术。请将小麦苗公众号置顶，小麦苗不喜欢被压着，~O(∩_∩)O~
小麦苗的今日寄语
无声的惦念，温暖的是心灵；
常常的想念，感动的是柔情。
（建议WIFI下观看）
今天给大家分享的是【等待事件】日志类 等待事件（4.3）--log file parallel write
等待事件历史文章~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
● 【故障处理】序列cache值过小导致CPU利用率过高
● 【故障处理】队列等待之enq: TX - row lock contention
● Oracle一次缩小表空间的处理过程
● 【故障处理】队列等待之TX - allocate ITL entry案例
● 【故障处理】队列等待之enq: US - contention案例
● 【故障处理】队列等待之TX - allocate ITL entry引起的死锁处理（上）
● 【故障处理】队列等待之TX - allocate ITL entry引起的死锁处理（下）--ITL死锁模拟
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
●【等待事件】等待事件概述（1）--等待事件的源起和分类
●【等待事件】User I/O类 等待事件（2.1）--db file sequential read（数据文件顺序读）
●【等待事件】User I/O类 等待事件（2.2）--db file scattered read（数据文件离散读）
●【等待事件】User I/O类 等待事件（2.3）--db file parallel read
● 【等待事件】User I/O类 等待事件（2.4）--db file single write
● 【等待事件】User I/O类 等待事件（2.5）--direct path read（直接路径读、DPR）
● 【等待事件】User I/O类 等待事件（2.6）--direct path write（直接路径写、DRW）
● 【等待事件】User I/O类 等待事件（2.7）--direct path read/write temp
● 【等待事件】User I/O类 等待事件（2.8）--read by other session
● 【等待事件】User I/O类 等待事件（2.9）--local write wait
● 【等待事件】User I/O类 等待事件（2.10）--所有User I/O类 等待事件总结
● 【等待事件】System I/O类 等待事件（3.1）--db file parallel write
● 【等待事件】System I/O类 等待事件（3.2）--control file parallel write
● 【等待事件】System I/O类 等待事件（3.3）--control file sequential read
● 【等待事件】System I/O类 等待事件（3.4）--control file single write
● 【等待事件】日志类 等待事件（4.1）--log file switch（日志文件切换）
● 【等待事件】日志类 等待事件（4.2）--log file sync（日志文件同步）
【等待事件】日志类 等待事件（4.3）--log file parallel write
SELECT * FROM V$EVENT_NAME A WHERE A.NAME LIke 'log file parallel write';
这个等待事件有三个参数：
Files： 操作需要写入的文件个数。
Blocks： 操作需要写入的数据块个数。
Requests：操作需要执行的I/O次数
在V$SESSION_WAIT这个视图里面，这个等待事件有三个参数P1、P2、P3，其中P1代表正在被写入的重做日志文件组中的重做日志文件号，P2代表需要写入重做日志组中每个重做日志文件的重做日志BLOCK数量，P3代表I/O请求的次数，需要被写入的BLOCK会被分成多次分别请求。
从Log Buffer写Redo记录到日志文件，主要指常规写操作（相对于Log File Sync）。如果Log Group存在多个组成员，当Flush Log Buffer时，写操作是并行的，这时候此等待事件可能出现。尽管这个写操作并行处理，直到所有I/O操作完成该写操作才会完成(如果你的磁盘支持异步IO或者使用IO SLAVE，那么即使只有一个redo log file member,也有可能出现此等待)。后台进程LGWR 负责将log buffer当中的数据写到REDO 文件中，以重用log buffer的数据。 如果每个REDO LOG组里面有2个以上的成员，那么LGWR进程会并行地将REDO 信息写入这些文件中。
这个等待事件出现在当LGWR后台进程从日志缓冲区写日志信息到磁盘上的重做日志文件的时候。只有启用了异步I/O的时候LGWR进程才会并行写当前日志组内的重做日志文件，否则LGWR只会循环顺序逐个的写当前日志组重做日志文件。LGWR进程不得不等待当前日志组所有的重做日志文件成员全部写完，因此，决定这个等待事件的等待时间长短的主要因素是重做日志文件所在磁盘的I/O读写的速度。
这个参数和log file sync 时间相比较可以用来衡量log file 的写入成本。通常称为同步成本率。
如果数据库中出现这个等待事件的瓶颈，主要的原因可能是磁盘I/O性能不够或者REDO 文件的分布导致了I/O争用，比如同一个组的REDO 成员文件放在相同的磁盘上。
如果是当前的LGWR进程写的速度不够快导致了这个等待事件，可以通过查看一些和重做日志相关的统计值判定当前的LGWR进程是否效率很低，具体的可以查看"redo writes"、"redo blocks written"、"redo write time"、"redo wastage"、"redo size"统计值，这些都是和LGWR进程性能直接相关的一些统计值。
如果这个等待事件占用的等待时间比较多，可以从以下几个方面来进行调整：
l 对能使用UNRECOVERABLE/NOLOGGING的操作尽量使用这两个选项来减少重做日志的产生。
l 在保证不会同时丢失重做日志文件的前提下尽量减少重做日志组中的成员的个数，减少每次写重做日志组文件的时间。
l 除非在备份的情况下，否则不要在将表空间置于热备的模式下，因为表空间处于热备的模式下会产生更多的重做日志文件。
l 对于使用LogMiner、Logical Standby或者Streams，在能够满足要求功能的前提下，尽量使用最低级别的追加日志以减少重做日志的产生。
l 尽量将同一个日志组内的重做日志文件分散到不同的硬盘上，减少并行写重做日志文件的时候产生的I/O竞争。
l 不要将重做日志文件放置在RAID-5的磁盘上，最好使用裸设备来存放重做日志文件。
l 如果设置了归档模式，不要将归档日志的目的地设置为存放重做日志存放的磁盘上面，避免引起I/O竞争。
当日志缓存到日志文件时,这是一个主要的等待事件.虽然这个时间的名字中有"并行"(parallel)字样,但即使日志缓存并没有使用并行写,因日志缓存的写出而造成的等待仍然是此等待事件.
我们可以通过v$system_event来了解下某一个阶段内,此等待事件的平均等待时间.通过此时间值,来评估我们的日志I/O是否正常.有资料介绍当log file parallel write的平均等待时间大于10毫秒时.有可能就表明着日志的吞吐量缓慢.我认为这只是一个参考值,在不同的系统上要根据不同的情况来决定.记录一些在正常情况下log file parallel write等待事件的平均等待时间,当出现问题后,以此时间作为是否有问题的标准.这种方法也是可取的.
当日志I/O确实有问题时,减少重做产生的数量,确实能够缓解log file parallel write的等待时间.但有时,重做信息的数量是无法减少的.根据情况,将日志I/O转移到更快速的磁盘上,也是解决问题的方法之一.
日志缓存的大小,有时候也会对此等待事件产生影响.如果你的日志缓存更大,会降低LGWR刷新缓存到磁盘的次数,增大日志的缓存,也会有助于缓解此等待事件.但过大的日志缓存,有可能会造成LGWR间歇性的拥堵.因为LGWR被触发的条件之一是日志缓存满1/3,如果日志缓存过大,1/3的日志缓存数量可能过多,每次LGWR被触发,不得不写大量数据,这造成LGWR间歇性的停顿与拥堵,这也会增加此等待事件的等待时间.我们可以通过设置隐藏参数_log_io_size来改变日志缓存满1/3才触发LGWR的阙值.通过设置此参数,我们即可以拥有较大的日志缓存,又避免了LGWR间歇性的停顿或拥堵.
我没有在生产库中使用过这个参数,因为他毕竟是一个隐藏参数.虽然据说他不会带来什么bug.在我的测试机上,通过调节这个参数,确实可以对性能略有提升.但这些都是为数据库的"微调".不可能带来大幅度的性能提升.
LGWR 在刷新缓存时,需要redo allocation和redo writing闩,并且LGWR需要等待一些redo copy 闩的完成.因此,如果这些闩的争用较高,则不要减少_log_io_size此隐藏参数,因为减少它,将会使LGWR更为频繁的刷新缓存.这会进一步加剧这3个闩的争用.减缓LGWR完成工作的速度.
**小小结:日志缓存到底应该设置为多大??_log_io_size参数的值应该定为多少??这没有一个统一的标准,只有通过多做测试才能决定.
从log buffer写Redo记录到日志文件，主要指常规写操作（相对于log file sync）。如果每
个日志组存在多个组成员，当flush log buffer时，写操作是并行的，这时此等待事件可能出现。
尽管这个写操作并行处理，直到所有I/O操作完成该写操作才会完成（如果磁盘支持异步
IO或者使用IO SLAVE，那么即使只有一个redo log file member，也有可能出现此等待）。这
个参数和log file sync时间相比较可以用来衡量log file的写入成本，通常称为同步成本率。
当数据库产生日志的速度比LGWR的写出速度快，或者是当日志切换（log switch）太慢
时，就会发生这种等待。这个等待出现时，通常表明redo log buffer过小，为解决这个问题，
可以考虑增大日志文件的大小，或者增加日志缓冲区的大小。
另外一个可能的原因是磁盘I/O存在瓶颈，可以考虑使用写入速度更快的磁盘。在允许的条件下，可以考虑使用裸设备来存放日志文件，ᨀ高写入效率。在一般的系统中，最低的标准是，不要把日志文件和数据文件存放在一起，因为通常日志文件只写不读，分离存放可以获得性能ᨀ升，尽量使用RAID10而不是RAID5磁盘来存储日志文件。以下是一个log buffer存在问题的Statspack Top5等待事件的系统：
Top 5 Wait Events
~~~~~~~~~~~~~~~ Wait % Total
Event Waits Time (cs) Wt Time
-------------------------------------------- ------------ ------------ -------
log file parallel write 1,436,993 1,102,188 10.80
log buffer space 16,698 873,203 9.56
log file sync 1,413,374 654,587 6.42
control file parallel write 329,777 510,078 5.00
db file scattered read 425,578 132,537 1.30
-------------------------------------------------------------
Log Buffer Space等待事件出现时，数据库将陷于停顿状态，所有和日志生成相关的操作全部不能进行，所以这个等待事件应该引起充分的重视。
● 本文作者：小麦苗，只专注于数据库的技术，更注重技术的运用
● 本文在itpub（http://blog.itpub.net/26736162）、博客园(http://www.cnblogs.com/lhrbest)和个人微信公众号（xiaomaimiaolhr）上有同步更新，推荐pdf文件阅读
● QQ群：230161599 微信群：私聊
● 本文itpub地址：http://blog.itpub.net/26736162/viewspace-2124737/ 博客园地址：http://www.cnblogs.com/lhrbest/articles/5854752.html
● 本文pdf版：http://yunpan.cn/cdEQedhCs2kFz （提取码：ed9b）
● 小麦苗分享的其它资料：http://blog.itpub.net/26736162/viewspace-1624453/
● 联系我请加QQ好友(642808185)，注明添加缘由
● 于 2016-09-08 09:00~2016-09-08 19:00 在泰兴公寓完成
● 【版权所有，文章允许转载，但须以链接方式注明源地址，否则追究法律责任】
长按识别二维码或微信客户端扫描下边的二维码来关注小麦苗的微信公众号：xiaomaimiaolhr,学习最实用的数据库技术。
本文分享自微信公众号 - DB宝（lhrdba）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。