Every commit issued2 and current mode buffer change (consistent read buffers do not have their changes recorded) must be recorded for recovery purposes. And the moment we are concerned with recovery, serialization becomes of critical importance. It's the combination of change recording and serialization that can force Oracle to place tremendous requirements on the operating system. When redo-related operating resources become scarce, response time begins to skyrocket, and the contention can be easily diagnosed by performing a wait-event analysis or a response-time analysis. If you perform the OraPub 3-circle analysis, within a few minutes, the performance story will be blatantly apparent.

The rule of thumb is that any buffer change results in redo generation. While cloned buffers are the exception, this rule of thumb will help when understanding redo generation and flow. There are two surprising examples of recording change that drive this point home. The first is associated with undo-related redo, and the second is query-related redo. But before we dive into the interesting situations, we need to discuss just what is actually recorded.

Oracle is obviously motivated to minimize the amount of redo generated. Every byte saved is one less byte of memory management, and also one less byte written to the IO subsystem. Buffer changes, called change vectors by Oracle kernel developers, are bundled into redo records (also called redo entries), which are copied into the redo log buffer and then into one of the online redo log groups by the log writer background process.