Oracle Internals Notes

Redo Latching

A process generating redo first takes the redo copy latch that will be needed for its copy into the log buffer. The redo copy latches are used to indicate that a process is copying redo into the log buffer, and that LGWR should wait until the copy has finished, before writing the target log buffer blocks to disk. No-wait mode is used for most gets against the redo copy latches, because the process can use any one of them to protect its copy into the log buffer. It first attempts to get the copy latch that it last held. Failing that, the process attempts to get each other copy latch in turn, in no-wait mode. Willing-to-wait mode is only used to get the last copy latch if no-wait gets against all the other copy latches have failed.

Once a redo copy latch has been acquired, the redo allocation latch must be taken to allocate space in the log buffer. This latch protects the SGA variables that are used to track which log buffer blocks are used and free. See our note on log buffer usage for an explanation of these variables. The amount of space allocated is that required for all of the change vectors comprising the logical database change, plus an allowance for a 16-byte block header at the beginning of each redo log block, if the redo entry spans the beginning of one or more log blocks. The redo allocation latch is released as soon as space has been allocated in the redo log buffer. The change vectors are then copied into the log buffer from temporary buffers in the PGA of the process.

From Oracle 8i, the redo copy latch is retained after the copy is complete while the change vectors are applied to the affected database blocks. Thereafter, the redo entry is marked as either VALID or INVALID in the log buffer before the redo copy latch is released. In this way, the validity of redo records can be confirmed before they are written to disk by LGWR. So even if an Oracle bug causes invalid redo to be generated, it will be marked as invalid in the redo stream before it gets written to the log files. Of course, recovery just skips any redo that is marked as INVALID.

At this point the process may need to post LGWR to signal that it should begin to flush the log buffer. This applies if the allocation raised the number of used blocks in the log buffer above the background write threshold, or if a commit marker has been copied into the redo stream and needs to be synced. However, to ensure that LGWR is not posted needlessly, the process takes the redo writing latch to check whether LGWR is already active or has already been posted. The redo writing latch is then released, and if appropriate the LGWR process is posted.

The redo allocation latch is needed again by processes waking up from log file sync waits, to check whether the log buffer block containing the redo of interest has yet been written to disk. If not, that process must continue to wait. The SGA variable that shows whether a particular log buffer block has yet been written to disk is the index into the log file representing the base disk block for the log buffer. This variable is of course protected by the redo allocation latch, and so the redo allocation latch must be taken to check it. Similarly, DBWn needs the redo allocation latch to check whether the high RBA of a set blocks that it intends to write has yet been synced.