第一点 ： ORACLE的确是扫描数据，找到要修改的数据后，再开始修改。从扫描开始到开始实施第一条修改这段时间中，数据不被保护，也没有数据需要保护。
我做如下一个实验。我先以全表扫描更新这个大表中的每一行，马上换到另一个会话，用ROWID更新同一行：
步1：先看看表有多少行：
sid=49 pid=18> select count(*) from test1;
  COUNT(*)
----------
    727232

步2：在49会话开始更新
sid=49 pid=18> update test1 set object_name=lower(object_name) where object_name='中国';

步3：马上换到43会话，更新ROWID='AAAC83AAEAAAD19AAh'的行，这一行上49会话中要更新的行中的一个：
sid=43 pid=19> update test1 set object_name=upper(object_name) where rowid='AAAC83AAEAAAD19AAh';
已更新 1 行。

步4： 回到49号会话看看，UPDATE被43号会话阻塞。
虽然43号会话中的更新比49号会话的更新晚，但是43号阻塞了49号，因为49号会话描述行的时间比较长。
也就是说，在49号会话找到要更新的数据前，它并不对行加锁。

首先，谢谢晶晶女侠，学习了，我再确定一下，那你的意思就是：
先进行扫描，扫描到符合修改条件的数据-->获取一个事务表项-->获取一个块ITL-->加锁-->进行数据的修改，是吗？在扫描到符合修改条件的数据前，即不获取事务表项，也不获取块上的ITL，对吗？如果按照这个顺序，那从查到一行符合修改条件的数据，到最后获取事务表项、ITL和行锁，这中间虽然时间非常短暂，这行符合修改条件的数据还是有机会被其他事务修改的，如果这期间被其他会话修改了，也许就不再满足被修改的条件，所以，我觉得肯定有某种机制在扫描前到加锁修改期间保护该行所在数据块不被其他会话扫描修改，是锁？闩？还是被暂时PIN住呢？一起探讨。

[ 本帖最后由 sqysl 于 2008-5-24 22:49 编辑 ]

补充一下，从程序设计的角度上说，ORACLE应该到真正找到要修改的数据了，再分配事务槽。因为如果没有找到满足条件的行，就省去了访问回滚段头的操作。
ORACLE中，能推后的操作，都推后执行。用户发出DML，此时没必要马上去分配事务槽的，都必须分配事务槽时，再去分配。

首先，谢谢晶晶女侠，学习了，我再确定一下，那你的意思就是：
先进行扫描，扫描到符合修改条件的数据-->获取一个事务表项-->获取一个块ITL-->加锁-->进行数据的修改，是吗？在扫描到符合修改条件的数据前，即不获取事务表项，也不获取块上的ITL，对吗？如果按照这个顺序，那从查到一行符合修改条件的数据，到最后获取事务表项、ITL和行锁，这中间虽然时间非常短暂，这行符合修改条件的数据还是有机会被其他事务修改的，如果这期间被其他会话修改了，也许就不再满足被修改的条件，所以，我觉得肯定有某种机制在扫描前到加锁修改期间保护该行所在数据块不被其他会话扫描修改，是锁？闩？还是被暂时PIN住呢？一起探讨。

QUOTE:

---

原帖由 sqysl 于 2008-5-24 22:28 发表
首先，谢谢晶晶女侠，学习了，我再确定一下，那你的意思就是：
先进行扫描，扫描到符合修改条件的数据-->获取一个事务表项-->获取一个块ITL-->加锁-->进行数据的修改，是吗？在扫描到符合修改条件的数据前，即不获取事务表项，也不获取块上的ITL，对吗？

---

是的。这里还有一个实验，可以证明不修改任何行的DML，根本不会访问回滚段头：

sid=36 pid=22> select tch,DBARFIL, DBABLK from x$bh a,(select header_file hf, header_block hb from dba_segments a , v$rollname b where a.segment_name=b.name) b where a.dbarfil=b.hf and a.dbablk=b.hb;
       TCH    DBARFIL     DBABLK
---------- ---------- ----------
        61          1          9
        43          7          9
        42          7         25
        41          7         41

  这上面显示的是回滚段头的TCH值。DBARFIL   是1的行，是系统回滚段，我们不必看它。主要看下面三行，TCH值分别是43，42，41，注意，相差1。
多观察几次：
sid=36 pid=22> /
       TCH    DBARFIL     DBABLK
---------- ---------- ----------
        62          1          9
        44          7          9
        43          7         25
        42          7         41

我观察了很多次，三个回滚段头的TCH值，都是相差1。

下面发出一个更新0行的DML：
sid=43 pid=19> update test1 set object_name='abcdefg' where object_name='9AAh';
已更新0行。

再到36号会话中观察回滚段头的TCH：
sid=36 pid=22> /

       TCH    DBARFIL     DBABLK
---------- ---------- ----------
        64          1          9
        46          7          9
        45          7         25
        44          7         41

sid=36 pid=22> /

       TCH    DBARFIL     DBABLK
---------- ---------- ----------
        65          1          9
        47          7          9
        46          7         25
        45          7         41

多观察几次，
sid=36 pid=22> /

       TCH    DBARFIL     DBABLK
---------- ---------- ----------
        70          1          9
        54          7          9
        53          7         25
        52          7         41

每个回滚段头的TCH始终都是相差1。这证明更新0行的DML并没有访问任何一个回滚段头。

下面，发出一个更新了1行的DML
sid=43 pid=19> update test1 set object_name='abcdefg' where object_name='abcdefg';
已更新 1 行。

sid=36 pid=22> /

       TCH    DBARFIL     DBABLK
---------- ---------- ----------
        71          1          9
        55          7          9
        55          7         25
        53          7         41

sid=36 pid=22> /

       TCH    DBARFIL     DBABLK
---------- ---------- ----------
        72          1          9
        56          7          9
        56          7         25
        54          7         41

第三行的回滚段头的TCH值发生了变化。

先说这么多吧。这个实验证明，UPDATE 零行的话，是不访问回滚段头的。

谢谢女侠，学习了

QUOTE:

---

原帖由 sqysl 于 2008-5-24 08:51 发表
...从查到一行符合修改条件的数据，到最后获取事务表项、ITL和行锁，这中间虽然时间非常短暂，这行符合修改条件的数据还是有机会被其他事务修改的，如果这期间被其他会话修改了，也许就不再满足被修改的条件，所以，我觉得肯定有某种机制在扫描前到加锁修改期间保护该行所在数据块不被其他会话扫描修改，是锁？闩？还是被暂时PIN住呢？一起探讨。

---

That's no different from a regular select, which is guaranteed to be a consistent read. If another session modifies some data and then this query reads it later, this query will go to undo to read the before image. Whether DML follows doesn't make any difference in the behavior.

Yong Huang

谢谢yong huang的回复，但我觉得你可能没理解我的意思，我的意思是在执行dml时，系统会扫描表，直到发现一条符合条件的数据行时，系统会获取一个事务槽，ITL，行锁。。。，那么在系统发现该数据行后，与获取事务槽之间，时间再短，也有个时间间隙的，我说的更改是在这个时间段内，被其他会话更改已经被该会话搜索到的数据行，我想在这个短的时间间隙内，应该有机制保护该会话找到的符合修改条件的数据行。如果在这个间隙该数据行被其他会话修改了，应该产生阻塞，而不是去回滚段里找前影像，我记得在修改块数据时数据块被PIN住，但不知道PIN的具体的时机，一起讨论。

在扫描块时，块上会加共享PIN，如果发现了满足条件行，释放共享PIN，重新获得Cache Bubffer Chain闩，在Buffer cache中定位块，在块中加独占PIN，然后修改ITL槽，加行锁。如果加独占PIN时发现块已经有了共享PIN或独占PIN，就等待。

应该就是这样吧。

这倒是比较符合逻辑，但这方面介绍这么细微的资料我至今也没找到，暂且这么认为吧，学习。