Using Figure 7-16 as our reference, let's take a close look at how traditional undo management works.

* Time T2: A transaction changes row 136 from a value of 105 to 110. This results in three key operations. First, the buffer (remember this is done in the buffer cache and not on disk) is changed. Second, the undo must be recorded in an undo segment buffer (remember this is done in the buffer cache and not on disk), and the undo link in buffer 142's interested transaction list (ITL) must point to undo buffer 210. And finally, the redo associated with each buffer's change must be recorded in the redo log buffer. All of these operations are performed in memory, but if a buffer is not in memory, it must first be retrieved from disk, a free buffer found, and the buffer replaced. And of course, all the associated latching, pinning, and memory and IO management must occur.

* Time T3: The transaction once again changes row 136. But this time, from a value of 110 to 115. First, buffer 142 is changed. Second, the buffer change is recorded in the undo buffer, and the buffer's ITL is updated to point to the most current undo entry in undo buffer 210. Third, the changes for both buffer 142 and the undo buffer 210 are copied into the redo log buffer. Notice the chain of undo has developed, allowing the transaction to roll back to time T1 and also allowing others to see row 136 at time T1 as well.