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

242
CHAPTER 7 ■ CONCURRENCY AND MULTI-VERSIONING
report need to be consistent with respect to a single point in time. In other systems, you would
use REPEATABLE READ and suffer the associated affects of the shared read lock. In Oracle, you
will use the READ ONLY transaction. In this mode, the output you produce in a report that uses
50 SELECT statements to gather the data will be consistent with respect to a single point in
time—the time the transaction began. You will be able to do this without locking a single piece
of data anywhere.
This aim is achieved by using the same multi-versioning as used for individual statements.
The data is reconstructed as needed from the rollback segments and presented to you
as it existed when the report began. READ ONLY transactions are not trouble-free, however.
Whereas you might see an ORA-08177 error in a SERIALIZABLE transaction, you expect to see an
ORA-1555: snapshot too old error with READ ONLY transactions. This will happen on a system
where other people are actively modifying the information you are reading. The changes
(undo) made to this information are recorded in the rollback segments. But rollback segments
are used in a circular fashion in much the same manner as redo logs. The longer the report
takes to run, the better the chance that some undo you need to reconstruct your data won’t
be there anymore. The rollback segment will have wrapped around, and the portion of it you
need we be reused by some other transaction. At this point, you will receive the ORA-1555 error
and have to start over again.
The only solution to this sticky issue is to have rollback segments that are sized correctly
for your system. Time and time again, I see people trying to save a few megabytes of disk space
by having the smallest possible rollback segments (“Why ‘waste’ space on something I don’t
really need?” is the thought). The problem is that the rollback segments are a key component
of the way the database works, and unless they are sized correctly, you will hit this error. In
16 years of using Oracle 6, 7, and 8, I can say I have never hit an ORA-1555 error outside of a
testing or development system. In such a case, you know you have not sized the rollback segments
correctly and you fix it. We will revisit this issue in Chapter 9.
Implications of Multi-Version Read Consistency
So far, we’ve seen how multi-versioning provides us with non-blocking reads, and I have
stressed that this is a good thing: consistent (correct) answers with a high degree of concurrency.
What could be wrong with that? Well, unless you understand that it exists and what
it implies, then you are probably doing some of your transactions incorrectly. Recall from
Chapter 1 the scheduling resources example whereby we had to employ some manual locking
techniques (via SELECT FOR UPDATE to serialize modifications to the SCHEDULES table by
resource). But can it affect us in other ways? The answer to that is definitely yes. We’ll go into
the specifics in the sections that follow.
A Common Data Warehousing Technique That Fails
A common data warehousing technique I’ve seen people employ goes like this:
1. They use a trigger to maintain a LAST_UPDATED column in the source table, much like
the method described in the last chapter, in the “Optimistic Locking” section.
2. To initially populate a data warehouse table, they remember what time it is right now
by selecting out SYSDATE on the source system. For example, suppose it is exactly
9:00 am right now.