Having a single redo allocation latch makes enforcing redo serialization very straightforward. But as you can imagine, having a single redo allocation latch also can become a point of contention. To reduce the likelihood of this, server processes hold the allocation latch just long enough to allocate redo log buffer space. There is also the instance parameter _log_small_entry_max_size, which is used to shift allocation latch activity onto one of the redo copy latches, as discussed in the "Redo Allocation Latch Contention" section later in this chapter. To further reduce the contention possibilities, Oracle allows for multiple redo copy latches. The instance parameter _log_simultaneous_copies is used to control the number of redo copy latches.

So, while having a single redo allocation latch may seem like a serious potential problem, for most Oracle systems, the problem can be solved entirely from an Oracle perspective. However, if you're responsible for one of those other Oracle systems, you may need something better.

When a single redo allocation latch is in use, which is the case prior to Oracle9i Release 2, the redo algorithm is very elegant and straightforward. But as Oracle systems continued to grow in concurrency and redo generation requirements, redo-related latch concurrency constraints started to become more likely. So, Oracle began making significant changes in the redo log buffer.