Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

CHAPTER 9 ■ REDO AND UNDO 285
■Note “Rollback segment” and “undo segment” are considered synonymous terms. Using manual undo
management, the DBA will create “rollback segments.” Using automatic undo management, the system will
automatically create and destroy “undo segments” as necessary. These terms should be considered the
same for all intents and purposes in this discussion.
It is a common misconception that undo is used to restore the database physically to the
way it was before the statement or transaction executed, but this is not so. The database is
logically restored to the way it was—any changes are logically undone—but the data structures,
the database blocks themselves, may well be different after a rollback. The reason for
this lies in the fact that, in any multiuser system, there will be tens or hundreds or thousands
of concurrent transactions. One of the primary functions of a database is to mediate concurrent
access to its data. The blocks that our transaction modifies are, in general, being modified
by many other transactions as well. Therefore, we cannot just put a block back exactly the way
it was at the start of our transaction—that could undo someone else’s work!
For example, suppose our transaction executed an INSERT statement that caused the allocation
of a new extent (i.e., it caused the table to grow). Our INSERT would cause us to get a
new block, format it for use, and put some data on it. At that point, some other transaction
might come along and insert data into this block. If we were to roll back our transaction, obviously
we cannot unformat and unallocate this block. Therefore, when Oracle rolls back, it is
really doing the logical equivalent of the opposite of what we did in the first place. For every
INSERT, Oracle will do a DELETE. For every DELETE, Oracle will do an INSERT. For every UPDATE,
Oracle will do an “anti-UPDATE,” or an UPDATE that puts the row back the way it was prior to our
modification.
■Note This undo generation is not true for direct path operations, which have the ability to bypass undo
generation on the table. We’ll discuss these in more detail shortly.
How can we see this in action? Perhaps the easiest way is to follow these steps:
1. Create an empty table.
2. Full scan the table and observe the amount of I/O performed to read it.
3. Fill the table with many rows (no commit).
4. Roll back that work and undo it.
5. Full scan the table a second time and observe the amount of I/O performed.