Another option similar to decreasing the redo log buffer size but without the likelihood of inducing log buffer space events is to force the log writer background process to flush well before the one-third or 1MB flush rule. As I mentioned, by carefully decreasing the hidden instance parameter _log_io_size, we can force the log writer background process to write redo more often. So when a server process commits, there is a higher likelihood of all but the commit entry already being written to the active online redo log group! There is a balance to maintain though, as rapid log writer writes typically mean less efficient and more IO write calls. You will need to carefully ensure response time improves along with the log file sync event wait time.

Through Oracle's wait interface, Oracle reports the log writer background process write time as the wait event, log file parallel write. As with other parallel wait events, this simply means a multiblock write. The redo log buffer is structured in relatively small operating system-size blocks (typically 512 bytes), not Oracle-size blocks, so it is normal for log writer activity to be performed with multiple blocks. When Oracle's redo generation requirements overpower the IO subsystem's capacity to quickly process the sequential multiblock writes, the log file parallel write wait event will be one of the top wait events (likely the top one).

On most Oracle systems, unless extremely rapid commits are occurring, the log writer background process will have a chance to batch 1MB of redo before the 1MB flush rule triggers the sequential multiblock write. Figure 8-10 shows a snippet of a typical active log writer operating system trace file.