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."

One of most surprising revelations when learning about Oracle internals is that, because all current buffer changes must be recorded, when an undo segment buffer changes, its change must also generate redo and therefore be recorded!