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.

As Figure 8-6 clearly shows, even an inactive log writer background process will wake up every 3 seconds, even if it's just to flush the general redo log buffer. However, in Oracle9i Release 2, which introduced redo strands, experiments demonstrate the entire redo log buffer is not flushed every 3 seconds; only the general redo log buffer is flushed.