关于重启动更新

qhd2004

看tom的书，发现一个restart the update
不明白什么restart the update
下面是实验过程，请刘大帮忙解释下
create table t (x int,y int);
insert into t values (5,5);
commit;
session A中：
SYK@ moe >select * from t;
         X          Y
---------- ----------
         5          5
SYK@ moe >update t set y=10 where y=5;
1 row updated.
SYK@ moe >select * from t;
         X          Y
---------- ----------
         5         10

session B中：
SYK@ moe >update t set x=x+1 where y=5;
不能更新，因为session A占有锁，我去session A中提交

session A中：
SYK@ moe >commit;
Commit complete.

回到session B中看发生什么
session B中：
SYK@ moe >update t set x=x+1 where y=5;
0 rows updated.
SYK@ moe >select * from t;
         X          Y
---------- ----------
         5         10
SYK@ moe >

tom说这是restart the update

Maclean Liu(刘相兵

至少把你看到的 文本贴一段出来， 或者 说出书名 章节  ， 不要断章取义

ricky

你想表达是什么？？？

qhd2004

Thomas.Kyte-Expert_Oracle_Database_Architecture(英文）.pdf
中的Consistent Reads and Current Reads这一节


下面是中文版的
Oracle 9i&10g编程艺术：深入数据库体系结构.pdf
里的7.4.1 一致读和当前读 这一节

下面是中文版里一段引用：
那么，读一致性对修改有什么影响呢？这么说吧，想像一下你正在对某个数据库表执行以下 UPDATE

语句：

     Update t set x = x+1 where y = 5;  

     我们知道，查询的 WHERE  Y=5 部分（即读一致阶段）会使用一个一致读来处理（TKPROF 报告中

的查询模式获取）。这个语句开始执行时表中已提交的 WHERE  Y=5 记录集就是它将看到的记录（假设使

用  READ  COMMITED  隔离级别，如果隔离级别是  SERIALIZABLE，所看到的则是事务开始是存在的

WHERE  Y=5 记录集）。这说明，如果 UPDATE 语句从开始到结束要花 5 分钟来进行处理，而有人在此期

间向表中增加并提交了一个新记录，其 Y 列值为 5，那么 UPDATE 看不到这个记录，因为一致读是看不到

新记录的。这在预料之中，也是正常的。但问题是，如果两个会话按顺序执行以下语句会发生什么情况呢？

     Update t set y = 10 where y = 5;

     Update t Set x = x+1 Where y = 5;  

     表 7-8 展示了这个时间表。

                                        表 7-8      更新序列

     时间           会话 1                 会话 2                                      注释

     T1        Update t                                          这会更新与条件匹配的一行
set y = 10

                where y = 5;

     T2                                Update t                  使用一致读 ，这会找到会话 1 修改的记录，

                                                                      但是无法更新这个记录，因为会话 1 已经

                                                                      将其阻塞。会话 2 将被阻塞，并等待这一行可用

                                        set x = x+1

                                        where y = 5;

     T3        Commit;                                           这会解放会话 2；会话 2 不再阻塞。他终于可以在

                                                                      包含这一行（会话 1 开始更新时 Y 等于 5 的那一行）

                                                                      的块上完成当前读

     因此开始 UPDATE 时 Y=5 的记录不再是 Y=5 了。UPDATE 的一致读部分指出：“你想更新这个记录，

因为我们开始时 Y 是 5”，但是根据块的当前版本，你会这样想：”噢，不行，我不能更新这一行，因为 Y

不再是 5 了，这可能不对。“

     如  果我们此时只是跳过这个记录，并将其忽略，就会有一个不确定的更新。这可能会破坏数据一致

性和完整性。更新的结果（即修改了多少行，以及修改了哪些行）将  取决于以何种顺序命中（找到）表中

的行以及此时刚好在做什么活动。在两个不同的数据库中，取同样的一个行集，每个数据库都以相同的顺

序运行事务，可能会观  察到不同的结果，这只是因为这些行在磁盘上的位置不同。

     在这种情况下，Oracle 会选择重启动更新。如果开始时 Y=5 的行现在包含值 Y=10，Oracle 会悄悄

地回滚更新，并重启动（假设使用的是 READ COMMITTED 隔离级别）。如果你使用了 SERIALIZABLE 隔

离级别，此时这个事务就会收到一个 ORA-08177：  can’t serialize access 错误。采用 READ COMMITTED

模式，事务回滚你的更新后，数据库会重启动更新（也就是说，修改更新相关的时间点），而且它并非重新

更新数据，而是进入 SELECT  FOR  UPDATE 模式，并试图为你的会话锁住所有 WHERE  Y=5 的行。一旦

完成了这个锁定，它会对这些锁定的数据运行 UPDATE，这样可以确保这一次就能完成而不必（再次）重

启动。

Maclean Liu(刘相兵

这段文字有什么问题吗？  tom 不是说的很清楚吗？

qhd2004

回滚中有y=5这个的映像，然后在session B中，我们去更新时，它应该会看到这个映像，我们更新时因为session A中锁定了。但是session提交后，这个锁没了，为什么会出现restart the update呢？

Maclean Liu(刘相兵

为什么会出现restart the update呢？


为什么不 出现？ 按照你的理解 oracle应当如何做？

qhd2004

是不是应该报个错呢？
如果restart the update，那碰巧另一个session把此行y改成5并commit了，那不就是事务之间会乱了。
如果y的值在其他session里又有改变，那不成死循环吗？

个人认为报个错，然后由我们再次手动update，这样好点吧？

[ 本帖最后由 qhd2004 于 2012-8-16 17:43 编辑 ]

Maclean Liu(刘相兵

1. 如果遇到 行锁争用，且更新列与条件列相关就 报错显然是不可接受的方案。

行锁依赖于TX LOCK事务锁，所以是有队列的，可以保证更新的顺序， 即先到的先更新。