* The server process copies its redo into the just-allocated space and releases its redo allocation latch.

When redo copy latches are not used by server processes for copying redo into the redo log buffer, the log writer background process will need to acquire all the redo allocation latches, just to make sure it doesn't flush the redo log buffer while server processes are busy copying their redo into the redo log buffer.

Figure 8-4 is a conceptual diagram of the log buffer based on Oracle9i Release 2 and later. Similar to the least recently used (LRU) strategy, Oracle conceptually divides the single large redo buffer into multiple parts, with each part having its own redo allocation latch. The two main parts are strands of redo and the general log buffer. Strands of redo are where server processes copy their redo into the redo log buffer. When a transaction commits, its strand of redo is flushed to the general log buffer, and the log writer flushes the entire general log buffer to the active online redo log group. Each strand of redo and also the general log buffer have their own redo allocation latch. So, the number of redo allocation latches can far exceed one.