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!

Keep in mind that redo is used for recovery. If we didn't need to recover, then redo would be a complete waste of resources. So, why would we ever need to recover undo segments? When you first learn about Oracle recovery, you come to understand there are two core phases to the recovery process: first, the system is rolled forward, and second, the system is rolled back. The other key nugget of information is that before the database writer will make a change to a block residing on a database (.dbf) file, that change absolutely must have already been written in an online redo log. Oracle must ensure any block change has already been recorded in the redo stream in case recovery is required. If this did not occur, an unfortunate recovery situation could exist where there is no record of a block change.