It's pretty obvious that having the log writer background process waiting until the redo log buffer fills to begin writing could cause serious performance problems. The log writer background process could potentially need to immediately write tens of megabytes. Plus, a user could have committed during a log writer background process flush and will need to wait for the write to complete, and then for the redo log buffer to fill once again. So, to avoid this type of performance behavior, if the log writer is not triggered to write for some other reason, it will flush the general log buffer when it is the minimum of one-third full, 1MB full, or reaches the value of the initialization parameter _log_io_size multiplied by the operating system block size. The operating system block size (in bytes) can be quickly determined by issuing the following code snippet:

There are times when we want to control redo log writing based on the amount of redo, not solely based on commits. For example, suppose a system is subjected to infrequent bursts of redo activity, but when these bursts occur, they result in very slow online user updates and inserts (not commits), and the top wait event is log buffer space. To address the log buffer space issue, the performance analyst may choose to increase the redo log buffer size. However, while the user's updates and inserts may complete quicker, commits may now take longer! Because the log writer background process is writing less frequently with a larger redo log buffer, it is likely to have more redo to flush to disk during each commit. If commit times become unacceptable, the performance analyst will need to find a way to optimally balance update and insert performance along with commit performance; that is, balance the log buffer space and the log file sync wait events.

One strategy is to increase the redo log buffer size, enabling it to absorb redo activity bursts, thereby reducing the likelihood of log buffer space wait events. Then decrease the _log_io_size parameter to ensure the log writer background process is performing more frequent, smaller redo log buffer flushes to keep performance smooth and consistent. However, be aware that if the _log_io_size parameter is set too small, the log writer would be making frequent and relatively small and inefficient writes, causing other problems. Once again, the performance analyst must find that elusive performance balance.