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.

The bad news is, as discussed earlier, pre-Oracle9i Release 2 systems have a single redo allocation latch, making it much more likely to experience redo allocation latch contention. The good news is there are multiple redo copy latches, and by creatively adjusting the _log_small_entry_max_size parameter, we can influence the likelihood of a process having to acquire the redo allocation latch.