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.

The implications of this are changes to undo segments must be recorded in the redo stream. So when an undo segment's cached block is changed, redo is generated. Put in a fuller context, when a row changes, its buffer is changed, and the associated redo is generated. And to enable rollback and read-consistency capabilities, an undo buffer is also changed, generating redo related to the undo buffer change. As I said, data management creates a tremendous amount of overhead.