Suppose a server process needs redo related to a buffer change. It creates the change vectors and combines them into a single redo entry. At this point, the server process knows how many bytes of redo are required.

Oracle9i Release 2 introduced significant changes in the redo log buffer architecture and algorithms. Yet, even prior to this release, there are adjustments the performance specialist can make to alter how Oracle's redo mechanism operates. Let's look at how the redo log buffer operates and some possible adjustments in both pre- and post-Oracle9i Release 2 versions.

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.