Redo and Undo - Oracle Database Transactions and Locking Revealed - page 107

■ With the advent of oracle 10 g , we now have flashback technology. This allows us to perform flashback queries
(query the data as of some point in time in the past), un-drop a database table, put a table back the way it was some
time ago, and so on. as a result, the number of occasions in which we need to perform a conventional recovery using
backups and archived redo logs has decreased. however, the ability to perform a recovery is the dBa's most important
job. database recovery is the one thing a dBa is not allowed to get wrong.

Note

Every Oracle database has at least two online redo log groups with at least a single member (redo log file) in each
group. These online redo log groups are written to in a circular fashion. Oracle will write to the log files in group 1, and
when it gets to the end of the files in group 1, it will switch to log file group 2 and begin writing to that one. When it
has filled log file group 2, it will switch back to log file group 1 (assuming you have only two redo log file groups; if you
have three, Oracle would, of course, proceed to the third group).
Redo logs, or transaction logs, are one of the major features that make a database a database. They are perhaps its
most important recovery structure, although without the other pieces such as undo segments, distributed transaction
recovery, and so on, nothing works. They are a major component of what sets a database apart from a conventional
file system. The online redo logs allow us to effectively recover from a power outage—one that might happen while
Oracle is in the middle of a write. The archived redo logs let us recover from media failures when, for instance,
the hard disk goes bad or human error causes data loss. Without redo logs, the database would not offer any more
protection than a file system.

What Is Undo?
Undo is conceptually the opposite of redo. Undo information is generated by the database as you make modifications
to data so that the data can be put back the way it was before the modifications took place. This might be done in
support of multiversioning, or in the event the transaction or statement you are executing fails for any reason, or if we
request it with a ROLLBACK statement. Whereas redo is used to replay a transaction in the event of failure—to recover
the transaction—undo is used to reverse the effects of a statement or set of statements. Undo, unlike redo, is stored
internally in the database in a special set of segments known as undo segments.

■ “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.

Note

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 r estored 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
can't just put a block back exactly the way it was at the start of our transaction—that could undo someone else's work!