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.

Developers tend to look at database changes from the table or row perspective. DBAs tend to look at changes from an Oracle block or buffer perspective. But Oracle kernel developers are not constrained by object, relational, or normalization concepts and their implementations. To an Oracle kernel developer, a database change is represented as one or more bytes. Oracle does not record the changed table, row, extent, or block. It simply records just enough information to, should it be necessary, redo the change. A kernel developer once told me, "Craig, you have got to stop thinking relational. Think bytes."