As strange as it might seem, decreasing the redo log buffer size can reduce the likelihood of receiving log file sync wait events. Because of the one-third full flush rule, a smaller redo log buffer will force the log writer background process to write more often. These flushes are not the result of commits, but rather the log writer background process being triggered. So when a commit does occur, there is a higher likelihood that all but the commit entry will have already been written to an online redo log group and the commit occurring instantly! However, as you're probably already thinking, if the log buffer is decreased too much, server processes will start posting log buffer space events. If response time is improving, this may be an acceptable compromise. But as always, we need to discover the optimal performance balance.

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).