WAITEVENT: "log file parallel write" Reference Note (文档 ID 34583.1)

"log file parallel write" Reference Note

This is a reference note for the wait event  "log file parallel write" which includes the following subsections: See  Note:61998.1 for an introduction to Wait Events.

Definition:

  • Versions:7.0 - 9.2 Documentation:None
  • This wait event is used when waiting for the writes of redo records to the redo log files to complete. The waits occur in log writer (LGWR) as part of normal activity of copying records from the redo log buffer to the current online log.

Individual Waits:

  Parameters:
  Wait Time:
The actual wait time is the time taken for all the outstanding I/O requests to complete. Even though the writes may be issued in parallel, LGWR needs to wait for the last I/O to be on disk before the parallel write is considered complete. Hence the wait time depends on the time it takes the OS to complete all requests.

Systemwide Waits:

As this wait is not used by normal Oracle shadow processes the "systemwide" figure should not be included directly in comparisons. If waits for "log file parallel write" are significant then this will show up as other user wait events (such as long "log file sync" wait times).

If the user waits indicate LGWR is not fast enough then the figures for this wait event, along with a number of redo related statistics, can help show if LGWR is suffering from poor IO response times.

For figures relating directly to LGWR write performance one can look at:

  • "redo writes" statistic
  • "redo blocks written" statistic
  • "redo write time" statistic
  • "redo wastage" statistic
  • "redo size" statistic

Reducing Waits / Wait times:

You might want to reduce "log file parallel write" wait times in order to reduce user waits which depend on LGWR.

  • Ensure tablespaces are NOT left in HOT BACKUP mode longer than needed.
    Tablespaces in HOT BACKUP mode cause more redo to be generated for each change which can vastly increase the rate of redo generarion.
  • Redo log members should ideally be on high speed disks 
    eg: RAID5 is not a good candidate for redo log members.
  • Redo log members should be on disks with little/no IO activity from other sources.
    (including low activity from other sources against the same disk controller)
  • NOLOGGING / UNRECOVERABLE operations may be possible for certain operations to reduce the overall rate of redo generation

Related:

<> 

 
 

相关内容

   
 
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值