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

326
CHAPTER 9 ■ REDO AND UNDO
will see a read-consistent view of T and the set of rows where X=2, regardless of any other concurrent
activity in the database.
■Note The four statements presented here are just examples of the types of statements that would see a
read-consistent view of T. They were not meant to be run as a single transaction in the database, as the first
update would cause the following three statements to see no records. They are purely illustrative.
All statements that “read” the table take advantage of this read consistency. In the example
just shown, the UPDATE reads the table to find rows where x=2 (and then UPDATEs them). The
INSERT reads the table to find where X=2, and then INSERTs them, and so on. It is this dual use
of the undo segments, both to roll back failed transactions and to provide for read consistency,
that results in the ORA-01555 error.
The third item in the previous list is a more insidious cause of ORA-01555, in that it can
happen in a database where there is a single session, and this session is not modifying the
tables that are being queried when the ORA-01555 error is raised! This doesn’t seem possible—
why would we need undo data for a table we can guarantee is not being modified? We’ll find
out shortly.
Before we take a look at all three cases with illustrations, I’d like to share with you the
solutions to the ORA-1555 error, in general:
• Set the parameter UNDO_RETENTION properly (larger than the amount of time it takes to
execute your longest running transaction). V$UNDOSTAT can be used to determine the
duration of your long-running queries. Also, ensure sufficient space on disk has been
set aside so the undo segments are allowed to grow to the size they need to be based on
the requested UNDO_RETENTION.
• Increase or add more rollback segments when using manual undo management. This
decreases the likelihood of undo data being overwritten during the course of your longrunning
query. This method goes toward solving all three of the previous points.
• Reduce the runtime of your query (tune it). This is always a good thing if possible, so it
might be the first thing you try. This will reduce the need for larger undo segments. This
method goes toward solving all three of the previous points.
• Gather statistics on related objects. This will help avoid the third point listed earlier.
Since the block cleanout is the result of a very large mass UPDATE or INSERT, this needs
to be done anyway after a mass UPDATE or large load.
We’ll come back to these solutions, as they are important facts to know. It seemed appropriate
to display them prominently before we begin.
Undo Segments Are in Fact Too Small
The scenario is this: you have a system where the transactions are small. As a result of this, you
need very little undo segment space allocated. Say, for example, the following is true: