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.

Figure 8-4. Shown is a less abstracted redo log buffer based on Oracle9i Release 2 and later. Similar to the log buffer shown in Figure 8-3, each strand of redo and the general log buffer have allocation and write markers. When DML occurs, space is allocated in a strand of redo, protected by one of the redo allocation latches. When a commit occurs, the related strand is flushed to the general log buffer, and then the general log buffer is flushed by the log writer background process.