05.11.2015 Views

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

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

CHAPTER 6 ■ LOCKING AND LATCHING 197<br />

DEPTNO DNAME<br />

BLOCKNO ORA_ROWSCN<br />

---------- -------------- ---------- ----------<br />

10 ACCOUNTING 20972 34676029<br />

20 RESEARCH 20972 34676029<br />

30 SALES 20973 34676029<br />

40 OPERATIONS 20973 34676029<br />

And sure enough, that is what we observe in this case. So, let’s update the row where<br />

DEPTNO = 10 is on block 20972:<br />

ops$tkyte@ORA10G> update dept<br />

2 set dname = lower(dname)<br />

3 where deptno = 10;<br />

1 row updated.<br />

ops$tkyte@ORA10G> commit;<br />

Commit complete.<br />

What we’ll observe next shows the consequences of ORA_ROWSCN being tracked at the block<br />

level. We modified <strong>and</strong> committed the changes to a single row, but the ORA_ROWSCN values of<br />

both of the rows on block 20972 have been advanced:<br />

ops$tkyte@ORA10G> select deptno, dname,<br />

2 dbms_rowid.rowid_block_number(rowid) blockno,<br />

3 ora_rowscn<br />

4 from dept;<br />

DEPTNO DNAME<br />

BLOCKNO ORA_ROWSCN<br />

---------- -------------- ---------- ----------<br />

10 accounting 20972 34676046<br />

20 RESEARCH 20972 34676046<br />

30 SALES 20973 34676029<br />

40 OPERATIONS 20973 34676029<br />

It would appear to anyone else that had read the DEPTNO=20 row that it had been modified,<br />

even though it was not. The rows on block 20973 are “safe”—we didn’t modify them, so they<br />

did not advance. However, if we were to update either of them, both would advance. So the<br />

question becomes how to modify this default behavior. Well, unfortunately, we have to<br />

re-create the segment with ROWDEPENDENCIES enabled.<br />

Row dependency tracking was added to the database with <strong>Oracle</strong>9i in support of<br />

advanced replication to allow for better parallel propagation of changes. Prior to <strong>Oracle</strong> 10g,<br />

its only use was in a replication environment, but starting in <strong>Oracle</strong> 10g we can use it to implement<br />

an effective optimistic locking technique with ORA_ROWSCN. It will add 6 bytes of overhead<br />

to each row (so it is not a space saver compared to the do-it-yourself version column) <strong>and</strong> that<br />

is, in fact, why it requires a table re-create <strong>and</strong> not just a simple ALTER TABLE: the physical<br />

block structure must be changed to accommodate this feature.<br />

Let’s rebuild our table to enable ROWDEPENDENCIES. We could use the online rebuild capabilities<br />

in DBMS_REDEFINITION (another supplied package) to do this, but for something so<br />

small, we’ll just start over:

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!