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.

Personally, I find it fascinating that, within Oracle, it is possible for a query to produce redo. In the previous chapter's discussion of the interested transaction list (ITL), I conveniently glossed over the fact that when a block cleanout occurs and the buffer changes, redo is generated. All it takes to trigger a cleanout (normally called a delayed block cleanout) is for the buffer to be touched by any session after a transaction commits. This causes the buffer to be cleaned out and the ITL flag to change from --U- to C---. The session that touches the buffer could be accessing the buffer as a result of a query. So a query can generate redo!