Prior to Oracle9i Release 2, the server process contends for one of the redo copy latches and then for the single redo allocation latch. Once both latches have been acquired, the server process gets the address of the last allocation pointer, which is marker MK100 in Figure 8-3. The server process adds the bytes it needs to marker MK100 and moves the pointer clockwise, perhaps to marker MK200. Now that space has been allocated, the server process immediately releases the single redo allocation latch for other processes to use. However, although the allocation latch has been released, the redo copy latch is still held while the server process copies the redo entry into the just-allocated space. The copy latch must be held to ensure the log writer background process does not flush the redo log buffer while a server process is copying its redo into the redo log buffer. Once the server process has finished copying its redo, it releases its redo copy latch.

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.