The log buffer space wait event is most common when a system is initially placed into production or a dramatic increase in redo generation occurs. Either way, a wonderfully simplistic Oracle-focused solution that usually fixes the problem is to increase the redo log buffer size by increasing the instance parameter log_buffer. However, besides wasting memory, if the log buffer becomes too large, other wait events, such as log file sync, can arise. So be conservative to avoid introducing other problems.

Once the redo log buffer has been expanded, increased pressure will be placed on the log writer background process and the IO subsystem. So, it is common to observe the performance issue shift further on down the redo flow toward a log file sync or log file parallel write wait event. Don't be discouraged by this, as it is normal and part of the tuning cycle. What you want to see is either the response time decreasing while workload remains the same or response time remaining the same while the workload increases. If your workload is OLTP-focused, then a drop is response time is usually preferred. If your workload is more batch-centric, a workload increase (the throughput) is typically your goal. Chapter 9 will help you understand your response time and throughput options.

If a process is spending too much time sleeping while acquiring a redo allocation latch, the latch free wait event associated with the redo allocation latch (pre-Oracle Database 10g) or the latch free: redo allocation (Oracle Database 10g and later) wait event will be your top wait event. This is most likely to occur in an intense high-concurrency environment. Fortunately, there is a straightforward Oracle-focused solution, which works with any Oracle release, that will probably resolve the issue.