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

196
CHAPTER 6 ■ LOCKING AND LATCHING
This example showed how to implement optimistic locking with a hash or checksum. You
should bear in mind that computing a hash or checksum is a somewhat CPU-intensive operation—it
is computationally expensive. On a system where CPU is a scarce resource, you must
take this fact into consideration. However, this approach is much more “network-friendly,” as
the transmission of a relatively small hash instead of a before and after image of the row (to
compare column by column) over the network will consume much less of that resource. Our
last example will use a new Oracle 10g function, ORA_ROWSCN, which is small in size like a hash,
but not CPU intensive to compute.
Optimistic Locking Using ORA_ROWSCN
Starting with Oracle 10g Release 1, you have the option to use the built-in ORA_ROWSCN function.
It works very much like the version column technique described previously, but it can
be performed automatically by Oracle—you need no extra column in the table and no extra
update/maintenance code to update this value.
ORA_ROWSCN is based on the internal Oracle system clock, the SCN. Every time you commit
in Oracle, the SCN advances (other things can advance it as well, but it only advances; it never
goes back). The concept is identical to the previous methods in that you retrieve ORA_ROWSCN
upon data retrieval, and you verify it has not changed when you go to update. The only reason
I give it more than passing mention is that unless you created the table to support the maintenance
of ORA_ROWSCN at the row level, it is maintained at the block level. That is, by default
many rows on a single block will share the same ORA_ROWSCN value. If you update a row on a
block with 50 other rows, then they will all have their ORA_ROWSCN advanced as well. This would
almost certainly lead to many false positives, whereby you believe a row was modified that in
fact was not. Therefore, you need to be aware of this fact and understand how to change the
behavior.
To see the behavior and then change it, we’ll use the small DEPT table again:
ops$tkyte@ORA10G> create table dept
2 (deptno, dname, loc, data,
3 constraint dept_pk primary key(deptno)
4 )
5 as
6 select deptno, dname, loc, rpad('*',3500,'*')
7 from scott.dept;
Table created.
Now we can inspect what block each row is on (it is safe to assume in this case they are in
the same file, so a common block number indicates they are on the same block). I was using
an 8KB block size with a row width of about 3,550 bytes, so I am expecting there to be two
rows per block for this example:
ops$tkyte@ORA10G> select deptno, dname,
2 dbms_rowid.rowid_block_number(rowid) blockno,
3 ora_rowscn
4 from dept;