Concurrency and Multiversioning - Expert Oracle Database Architecture - page 252

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 nonblocking reads. As we have seen, Oracle provides for nonblocking 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 and write to the database; all DML statements have this ability. The case of a single row
INSERT using the VALUES clause is the only exception, 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 that 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 multiversioning, 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, assume 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

Now, our select statement starts executing and reads row 1, row 2, and so on.

■ I do not mean to imply that rows have any sort of physical ordering on disk in this example. There really is not
a first row, second row, or last row in a table. There is just a set of rows. We are assuming here that row 1 really means
“the first row we happened to read” and row 2 is the second row we happened to read and so on.

Note

At some point while we are in the middle of the query, a transaction moves $400.00 from account 123 to account
987. This transaction does the two updates but does not commit. The table now looks as shown in Table 7-3 .