非空闲的等待事件-log file parallel write

log file parallel write SYSTEM I/0类)

1. LGWR专属事件,将日志缓冲区中的重做信息写入到联机重做日志组的所有成员,LGWR在该事件上等待写入的完成。

2. 写入时机:

>> 每隔3秒写入一次

>> 在提交或回滚时

>> 在满足_LOG_IO_SIZE阈值时

>> 在日志缓冲区有1MB的重做项时

>> DBWR提交时

3. 用户会话提交事务时,LGWR会等待该事件的完成,用户会话则等待log file sync事件。

[@more@]
  1. 该事件的等待表示重做日志所处的磁盘设备缓慢或存在争用。

SELECT s.event, s.time_waited, s.average_wait
FROM v$system_event s
WHERE s.event IN ('log file parallel write', 'log file sync')

注:'log file parallel write'事件的平均等待时间大于10ms(1cs),这通常表示存在缓慢的IO吞吐量。

  1. 如果该事件的等待时间过长,除了改进IO吞吐量外,

也可以设法降低重做的数量。

>> 只要有可能就使用NOLOGGING选项。

>> CTAS操作也应该使用该选项。

也可以以较高的回滚段使用率为代价的较低提交频率,来缓解一些IO需求,使用以下SQL查出谁在频繁提交数据:

SELECT sid, VALUE
FROM v$sesstat s
WHERE s.statistic# =
(SELECT statistic# FROM v$statname WHERE NAME = 'user commits')
ORDER BY VALUE

SELECT b.NAME, a.VALUE, round(SYSDATE - c.startup_time) day_old
FROM v$sysstat a, v$statname b, v$instance c
WHERE a.statistic# = b.statistic#
AND b.NAME IN ('redo wastage', 'redo size')

注:由于LGWR不象DBWR那样能够有多个,所以尽可能将REDO放在IO快的磁盘结构上,不要放在象RAID5这样的磁盘上。

  1. 热备可能创建大量的重做项,从而增加log file parallel write等待事件,所以热备份应该在非高峰时间内运行,并且应该尽可能将表空间排除在热备份模式外。
  2. 注意不要同时使用过多的重做项堵塞LGWR。可以使用下需的查询来找到每次写入的平均重做日志块的数量,以及以字节为单位的LGWR IO平均大小:

SELECT round((a.VALUE / b.VALUE) + 0.5, 0) AS avg_redo_blks_per_write,
round((a.VALUE / b.VALUE) + 0.5, 0) * c.lebsz AS avg_io_size -- 字节为单位
FROM v$sysstat a, v$sysstat b, x$kccle c
WHERE c.lenum = 1
AND a.NAME = 'redo blocks written'
AND b.NAME = 'redo writes'

注:x$kccle.lebsz字段包含每个日志块的大小。

  1. 参数说明:

事件号:176

事件名:log file parallel write

参数一:写入的日志文件号

参数二:写入的块数

参数三:IO请求的号码

  1. 等待时间:完成所有IO所占用的实际时间。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/79291/viewspace-910244/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/79291/viewspace-910244/

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值