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

CHAPTER 7 ■ CONCURRENCY AND MULTI-VERSIONING 247
the current value for Y is now 6—it’s not 5 anymore—and before updating the value of X,
Oracle will check to see that Y is still 5. Now what happens? How are the updates affected
by this?
Obviously, we cannot modify an old version of a block—when we go to modify a row, we
must modify the current version of that block. Additionally, Oracle cannot just simply skip this
row, as that would be an inconsistent read and unpredictable. What we’ll discover is that in
such cases, Oracle will restart the write modification from scratch.
Consistent Reads and Current Reads
Oracle does do two types of block gets when processing a modification statement. It performs
• Consistent reads: When “finding” the rows to modify
• Current reads: When getting the block to actually update the row of interest
We can see this easily using TKPROF. Consider this small one-row example, which reads
and updates the single row in table T from earlier:
ops$tkyte@ORA10GR1> alter session set sql_trace=true;
Session altered.
ops$tkyte@ORA10GR1> select * from t;
X
----------
10001
ops$tkyte@ORA10G> update t t1 set x = x+1;
1 row updated.
ops$tkyte@ORA10G> update t t2 set x = x+1;
1 row updated.
When we run TKPROF and view the results, we’ll see something like this (note that I
removed the ELAPSED, CPU, and DISK columns from this report):
select * from t
call count query current rows
------- ------ ------ ---------- ----------
Parse 1 0 0 0
Execute 1 0 0 0
Fetch 2 3 0 1
------- ------ ------ ---------- ----------
total 4 3 0 1
update t t1 set x = x+1