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.

Part of the rolling forward process is re-creating the undo segments. Just like data and index segments, undo segments are rolled forward during the first recovery phase. When the roll forward process has completed, the database file blocks contain both committed and uncommitted changes. This also means the re-created undo segments contain information about both uncommitted (active) and committed (inactive) transactions. Remember the previous chapter's discussion about the transaction table? Each undo segment header block contains the transaction table, which has a record of all the transaction information contained in its associated undo segment. The recovery process accesses this information, and then proceeds to roll back all uncommitted transactions. When this rolling back portion of the recovery process is complete, the database can open in a consistent, point-in-time state.