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

CHAPTER 7 ■ CONCURRENCY AND MULTI-VERSIONING 251
As you can see, that row trigger saw two versions of that row here. The row trigger was
fired two times: once with the original version of the row and what we tried to modify that
original version to, and again with the final row that was actually updated. Since this was a
BEFORE FOR EACH ROW trigger, Oracle saw the read-consistent version of the record and the
modifications we would like to have made to it. However, Oracle retrieved the block in current
mode to actually perform the update after the BEFORE FOR EACH ROW trigger fired. It waits until
after this trigger fires to get the block in current mode, because the trigger can modify the
:NEW values. So Oracle cannot modify the block until after this trigger executes, and the trigger
could take a very long time to execute. Since only one session at a time can hold a block in
current mode, Oracle needs to limit the time we have it in that mode.
After this trigger fired, Oracle retrieved the block in current mode and noticed that the
column used to find this row, X, had been modified. Since X was used to locate this record and
X was modified, the database decided to restart our query. Notice that the update of X from
1 to 2 did not put this row out of scope; we’ll still be updating it with this UPDATE statement.
Rather, it is the fact that X was used to locate the row, and the consistent read value of X (1 in
this case) differs from the current mode read of X (2). Now, upon restart, the trigger sees the
value of X=2 (following modification by the other session) as the :OLD value and X=3 as the
:NEW value.
So, that shows that these restarts happen. It takes a trigger to see them in action; otherwise,
they are generally “undetectable.” That does not mean you cannot see other symptoms—such
as a large UPDATE statement rolling back work after updating many rows and then discovering a
row that causes it to restart—just that it is hard to definitively say, “This symptom is caused by
a restart.”
An interesting observation is that triggers themselves may cause restarts to occur even
when the statement itself doesn’t warrant them. Normally, the columns referenced in the
WHERE clause of the UPDATE or DELETE statement are used to determine whether or not the modification
needs to restart. Oracle will perform a consistent read using these columns and, upon
retrieving the block in current mode, it will restart the statement if it detects that any of them
have changed. Normally, the other columns in the row are not inspected. For example, let’s
simply rerun the previous example and use WHERE Y>0 to find the rows:
ops$tkyte@ORA10G> update t set x = x+1 where y > 0;
old.x = 1, old.y = 1
new.x = 2, new.y = 1
old.x = 2, old.y = 1
new.x = 3, new.y = 1
1 row updated.
You might at first wonder, “Why did Oracle fire the trigger twice when it was looking at the
Y value? Does it examine the whole row?” As you can see from the output, the update was in
fact restarted and the trigger again fired twice, even though we were searching on Y>0 and did
not modify Y at all. But, if we re-create the trigger to simply print out the fact that it fired,
rather than reference the :OLD and :NEW values
ops$tkyte@ORA10G> create or replace trigger t_bufer
2 before update on t for each row
3 begin
4 dbms_output.put_line( 'fired' );