Figure 8-5. Shown is a system with a defined 4,000 Oracle process limit, resulting in 488 redo allocation latches. The system is undergoing an intense three-process DML workload.

Now that I've laid the architectural foundation, let's see how this is combined into the flow of redo.

A good word picture of redo flow is a river. Changes made to database buffers can be thought of as a storm. The rain comes pouring down in the form of change vectors, which are consolidated into redo entries. Space is allocated in the redo log buffer for the redo entries. Then the redo entries are copied into the redo log buffer. Finally, the redo buffer contents are written into an online redo log group. To summarize, there is redo creation, redo space allocation, redo copying, and redo writing. Anywhere in this flow of redo, contention can occur. And as with an overflowing river, we need to ensure Oracle's redo requirements do not exceed the IO subsystem's capacity. Otherwise, a flood of performance problems will develop.