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.

By default, the number of redo strands is dynamic, but it can be made static by setting the hidden instance parameter _log_parallelism_dynamic to false. When Oracle is dynamically controlling the number of redo strands, the maximum number of strands is controlled by the hidden instance parameter _log_parallelism_max. The DBA can specifically set the number of redo strands via the hidden parameter _log_parallelism. The default number of redo strands is surprisingly low-perhaps two.