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

234
CHAPTER 7 ■ CONCURRENCY AND MULTI-VERSIONING
inserts, updates, and deletes are not permitted in this mode (other sessions may update data,
but not the READ ONLY transaction). Using this mode, you can achieve REPEATABLE READ and
SERIALIZABLE levels of isolation.
Let’s now move on to discuss exactly how multi-versioning and read consistency fits into
the isolation scheme, and how databases that do not support multi-versioning achieve the
same results. This information is instructive for anyone who has used another database and
believes he or she understands how the isolation levels must work. It is also interesting to
see how a standard that was supposed to remove the differences between the databases,
ANSI/ISO SQL, actually allows for them. The standard, while very detailed, can be implemented
in very different ways.
READ UNCOMMITTED
The READ UNCOMMITTED isolation level allows dirty reads. Oracle does not make use of dirty
reads, nor does it even allow for them. The basic goal of a READ UNCOMMITTED isolation level is
to provide a standards-based definition that caters for non-blocking reads. As we have seen,
Oracle provides for non-blocking reads by default. You would be hard-pressed to make a
SELECT query block in the database (as noted earlier, there is the special case of a distributed
transaction). Every single query, be it a SELECT, INSERT, UPDATE, MERGE, or DELETE, executes in a
read-consistent fashion. It might seem funny to refer to an UPDATE statement as a query—but it
is. UPDATE statements have two components: a read component as defined by the WHERE clause
and a write component as defined by the SET clause. UPDATE statements read from and write
to the database—as do all DML statements. The special case of a single row INSERT using the
VALUES clause is the only exception to this, as such statements have no read component, just
the write component.
In Chapter 1, Oracle’s method of obtaining read consistency was demonstrated by way
of a simple single table query, which retrieved rows that were deleted after the cursor was
opened. We’re now going to explore a real-world example to see what happens in Oracle using
multi-versioning, as well as what happens in any number of other databases.
Let’s start with the same basic table and query:
create table accounts
( account_number number primary key,
account_balance number not null
);
select sum(account_balance) from accounts;
Before the query begins, we have the data shown in Table 7-2.
Table 7-2. ACCOUNTS Table Before Modifications
Row Account Number Account Balance
1 123 $500.00
2 456 $240.25
. . . . . . . . .
342,023 987 $100.00