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

CHAPTER 9 ■ REDO AND UNDO 323
Investigating Undo
We’ve already discussed a lot of undo segment topics. We’ve seen how they are used during
recovery, how they interact with the redo logs, and how they are used for consistent, nonblocking
reads of data. In this section, we’ll look at the most frequently raised issues with
undo segments.
The bulk of our time will be spent on the infamous ORA-01555: snapshot too old error, as
this single issue causes more confusion than any other topic in the entire set of database topics.
Before we do this, however, we’ll investigate one other undo-related issue in the next
section: the question of what type of DML operation generates the most and least undo (you
might already be able to answer that yourself, given the preceding examples with temporary
tables).
What Generates the Most and Least Undo?
This is a frequently asked but easily answered question. The presence of indexes (or the fact
that a table is an index-organized table) may affect the amount of undo generated dramatically,
as indexes are complex data structures and may generate copious amounts of undo
information.
That said, an INSERT will, in general, generate the least amount of undo, since all Oracle
needs to record for this is a rowid to “delete.” An UPDATE is typically second in the race (in most
cases). All that needs to be recorded are the changed bytes. It is most common that you UPDATE
some small fraction of the entire row’s data. Therefore, a small fraction of the row must be
remembered in the undo. Many of the previous examples run counter to this rule of thumb,
but that is because they update large, fixed-sized rows, and they update the entire row. It is
much more common to UPDATE a row and change a small percentage of the total row. A DELETE
will, in general, generate the most undo. For a DELETE, Oracle must record the entire row’s
before image into the undo segment. The previous temporary table example, with regard to
redo generation, demonstrated that fact: the DELETE generated the most redo, and since the
only logged element of the DML operation on a temporary table is the undo, we in fact
observed that the DELETE generated the most undo. The INSERT generated very little undo that
needed to be logged. The UPDATE generated an amount equal to the before image of the data
that was changed, and the DELETE generated the entire set of data written into the undo
segment.
As previously mentioned, you must also take into consideration the work performed on
an index. You will find that an update of an unindexed column not only executes much faster,
but will tend to generate significantly less undo than an update of an indexed column. For
example, we’ll create a table with two columns both containing the same information and
index one of them:
ops$tkyte@ORA10G> create table t
2 as
3 select object_name unindexed,
4 object_name indexed
5 from all_objects
6 /
Table created.