当前模式读与一致性读（自我改版）

来源：互联网发布：暗影格斗2mac存档编辑：程序博客网时间：2024/06/18 17:39

当前模式读与一致性读

[English]

作者：fuyuncat

来源：www.HelloDBA.com

日期：2011-05-03 03:55:10

    让我从以下2个例子展开我们的探讨。
    例1:
初始条件：
HELLODBA.COM>set time on
10:22:09 HELLODBA.COM>update t_test1 set SECONDARY='A' where object_id = -1;

1 row updated.

10:22:22 HELLODBA.COM>commit;

Commit complete.
开始实验：

Session 1:
10:22:25 HELLODBA.COM>update t_test1 set SECONDARY='B' where object_id = -1 and SECONDARY='B' and (select count(*) from t_test2 t1, t_test2 t2) > 0;

0 rows updated.

10:23:15 HELLODBA.COM>

Session 2:
10:22:37 HELLODBA.COM>update t_test1 set SECONDARY='B' where object_id = -1;

1 row updated.

10:23:02 HELLODBA.COM>commit;

Commit complete.

10:23:04 HELLODBA.COM>

例2:
10:25:38 HELLODBA.COM>update t_test1 set SECONDARY='A' where object_id = -1;

1 row updated.

10:25:48 HELLODBA.COM>commit;

Commit complete.

Session 1:
10:26:05 HELLODBA.COM>update t_test1 set SECONDARY='B' where object_id = -1 and SECONDARY='A' and (select count(*) from t_test2 t1, t_test2 t2) > 0;

0 rows updated.

10:27:21 HELLODBA.COM>

Session 2:

10:26:16 HELLODBA.COM>update t_test1 set SECONDARY='B' where object_id = -1;

1 row updated.

10:26:41 HELLODBA.COM>commit;

Commit complete.

10:26:42 HELLODBA.COM>
    如果你观察得足够仔细，你可以从上面2个例子看到一个有趣的现象：无论session 1是否命中（找）到数据，it（它）最终都没有修改数据。其根本原因就是当前模式读与一致性读的区别。
    我们知道，为了减少并发冲突，Oracle引入了MVCC（多版本并发控制，也叫MCC）方法。在这种机制中，并发事务不会因为一致性的原因而相互阻塞，除非他们要修改同一条记录。他们会将日志中所有SCN大于本身事务SCN的日志做回滚，以保证本事务读取到的数据块与事务SCN的一致。在Oracle中，这样的读取行为就称为一致性读。
    然而，一致性读所读取到数据块仅仅是某个时间点的一个快照，也就是说这样的数据是只读的。如果要修改数据，那么oracle需要读取到当前的数据块，也就是当前模式读。
    在一个UPDATE过程中，oracle会先一致性读取与事务SCN一致的数据快照，并用where条件进行过滤。让后根据读取到数据块的ID，再从当前数据中读取到相应的数据块进行修改。但是，如在事务（上的操作）启动后到数据块被读取之间的这段时间内，相应的数据块发生了改变（为什么在这段时间内相应的数据块（指的是buffer cache上的数据块，也就是当前模式的数据块）可以发生改变呢？因为这段时间就是操作的一致性读取的过程，此时该操作是不会锁住这些数据块的，其他进程故而可以修改这些数据块。而过了这段时间后，该操作会锁住这些数据块的，其他进程故而修改不了这些数据块），那么可能就会有我们意想不到的事情发生。
    往回看我们的第一个例子。我们在session 1中，在10:22:25启动了update事务。但是，由于该事务中存在一个大的子查询，它会在几十秒后才会读取到需要被修改的数据（具体说，子查询就是(select count(*) from t_test2 t1, t_test2 t2) ，外层的update语句要等到子查询得出结果集（要几十秒的时间）后才能开始自己的第一个过程，就是一致性读取的过程）。在Session 2中，我们在10:22:37开始update这些数据并在10:23:02提交了事务。而这个提交的时间（10:23:02）是晚于session 1中update开始执行的时间（10:22:25）的。因此，session 1中update开始执行一致性读取的过程时，会读取UNDO中的数据（即初始条件里update后的内容，因为该update语句的提交时间（10:22:22）早于且接近一致性读取的过程）进行回滚，也就是说它读取到数据SECONDARY是'A'，再通过条件(SECONDARY='B')过滤后，没有数据被命中，因此也没有数据被修改。而这个时间是早于数据在session 1中被读取到的时间的。当session 2中的数据改变被提交后，session 1中的事务读取到了该数据块。因为session 2中的事务SCN大于session 1中的事务SCN，因此会读取UNDO中的数据进行回滚，也就是说它读取到数据SECONDARY是'A'，再通过条件(SECONDARY='B')过滤后，没有数据被命中，因此也没有数据被修改。
    在第二个例子中，session 1的事务在一致性读取到数据块之前也发生了类似的事情。当它回滚了数据后，它一致性读取到了满足过滤条件(SECONDARY='A')的数据块。此时，它需要通过该数据块ID再到当前数据中读取该数据块。但是因为当前数据块的内容已经是SECONDARY='A'（被session 2中的事务所修改），故而它还是没有能修改到数据。
    我想，通过这两个例子，读者应该更容易理解到当前模式读与一致性读之间的区别。
--- Fuyuncat ---
在前一篇文章里，我用2个特殊例子描述当前模式读和一致性读之间的区别，并提到了“如在事务启动后到数据块被读取之间的这段时间内，相应的数据块发生了改变，那么可能就会有我们意想不到的事情发生”。而这样的意想不到的结果可能能被我们接受，但也可能难以被接受。
    我们先看一下以下2条UPDATE语句：
SQL代码
1:
update t_test1 set lio=0where object_idin (101,102);
2:
update t_test1 set lio=(select liofrom t_test1where object_id = 101)where object_id = 102and (selectcount(*)from t_test2 t1, t_test2 t2) > 0;
    从逻辑角度来说，无论运行了那条语句，我们希望两条记录（object_id=101和object_id=102）的lio都相同。
    然而，由于UPDATE语句会同时引入一致性读和当前模式读，并且由于这两种读之间存在时间差，我们可能会得到不希望出现的结果。
    这里我们演示一个例子。
SQL代码
13:27:23 HELLODBA.COM>update t_test1set lio=1where object_idin (101,102);

2 rows updated.

13:29:06 HELLODBA.COM>commit;

Commit complete.

Session 1:
13:29:06 HELLODBA.COM>alter system flush buffer_cache;

System altered.

13:29:11 HELLODBA.COM>-- Transaction 1 begin ---
13:29:11 HELLODBA.COM>update t_test1set lio=(select liofrom t_test1where object_id = 101)where object_id = 102and (selectcount(*)from t_test2 t1, t_test2 t2) > 0;

1 row updated.

13:29:25 HELLODBA.COM>commit;

Commit complete.

13:29:25 HELLODBA.COM>-- Transaction 1 end ---
13:29:25 HELLODBA.COM>select object_id, liofrom t_test1 twhere object_idin (101,102);

OBJECT_ID        LIO
---------- ----------
       101          0
       102          1

13:29:25 HELLODBA.COM>

Session 2:

13:29:11 HELLODBA.COM>-- Transaction 2 begin ---
13:29:16 HELLODBA.COM>update t_test1set lio=0where object_idin (101,102);

2 rows updated.

13:29:16 HELLODBA.COM>commit;

Commit complete.

13:29:16 HELLODBA.COM>-- Transaction 2 end ---
    在这个例子中，我们并发执行了上面两条语句，但最终得到一个和我们逻辑目标相左的结果。
    事务1的SCN早于事务2的SCN，因此它用了一个快照数据（由一致性读得到的老的数据，即update t_test1set lio=(select liofrom t_test1where object_id = 101)where object_id = 102and (selectcount(*)from t_test2 t1, t_test2 t2) > 0;中的select liofrom t_test1where object_id = 101他是select语句，而select语句的结果集是一致性读得到的老的数据的）来更新了当前数据（由当前模式读得到的最新的数据，即update t_test1set lio=(select liofrom t_test1where object_id = 101)where object_id = 102and (selectcount(*)from t_test2 t1, t_test2 t2) > 0;的外层就是update语句，他是DML语句，DML语句修改的是当前模式的数据块）。
    我不能说这算不算MVCC的一个缺陷，但它最少已经造成了逻辑混乱。
--- Fuyuncat ---