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.

Any time there is a redo-related performance problem, you will find the issues will be concentrated into one of these main redo areas: redo creation, space allocation, redo copying, and redo writing. As I present the various performance-hindering situations, pay close attention to where in the redo flow the problems occur. Understanding and visualizing the redo flow blockage will help you and your colleagues avoid nonsensical solutions (guessing) and also communicate your ideas better to others.