log file parallel write
The LGWR background process waits for this event while it is copying redo
records from the memory Log Buffer cache to the current redo group’s member
logfiles on disk.
Asynchronous I/O will be used if available to make the write parallel, otherwise
these writes will be done sequentially one member after the other.
However, LGWR has to wait until the I/Os to all member logfiles are complete
before the wait is completed.
Hence, the factor that determines the length of this wait is the speed with
which the I/O subsystem can perform the writes to the logfile members.
To reduce the time waited for this event, one approach is to reduce the amount
of redo generated by the database:
o Make use of UNRECOVERABLE/NOLOGGING options.
o Reduce the number of redo group members to the minimum necessary to ensure
not all members can be lost at the same time.
o Do not leave tablespaces in BACKUP mode for longer than necessary.
o Only use the minimal level of Supplemental Logging required to achieve
the required functionality e.g. in LogMiner, Logical Standby or Streams.
Another approach is to tune the I/O itself:
o Place redo group members on storage locations so that parallel
writes do not contend with each other.
o Do not use RAID-5 for redo logfiles.
o Use Raw Devices for redo logfiles.
o Use faster disks for redo logfiles.
o If archiving is being used setup redo storage so that writes for the current
redo group members do not contend with reads for the group(s) currently being
archived.
