深入解析:你听说过Oracle数据库的更新重启动吗?

简介: 更新重启动是 Oracle 中一个隐藏的知识点,当 Oracle 在读取数据时,会构造读一致性,当读取的内容发生了修改,Oracle 会通过 UNDO 信息来还原数据的前镜像,把数据还原到查询发生的时刻,通过构造一致性的结果来实现读取数据的一致性和隔离性。

最近看到一个比较有意思的例子,是和更新重启动有关。

更新重启动是 Oracle 中一个隐藏的知识点,当 Oracle 在读取数据时,会构造读一致性,当读取的内容发生了修改,Oracle 会通过 UNDO 信息来还原数据的前镜像,把数据还原到查询发生的时刻,通过构造一致性的结果来实现读取数据的一致性和隔离性。

Oracle 实现的读一致性也被称为多版本读一致性,每个会话都会构造自己的一致性查询版本。但是对于写操作而言,这种方式是不可能的,因为最终的数据只有一份,如要要修改数据,就只能修改唯一的这份数据,所以对读操作,访问的是一致性版本,而对于写操作,修改的永远是当前版本。

既然写操作只能修改当前版本,当写操作执行的过程中,发现要修改的记录发生了变化,破坏了更新发起时刻的一致性,这时就触发了更新重启动,也就是说更新操作会放弃之前的修改,然后重新发起一次新的更新操作。

案例一

ITPUB 上有一个有意思的案例,展示的就是更新重启动现象,链接如下:
http://www.itpub.net/forum.php?mod=viewthread&tid=2102897

这里来重现一下更新重启动,建立一张简单测试用表,在会话一插入初始数据并进行更新操作:

SQL> SET SQLP 'SQL1> '
SQL1> CREATE TABLE T_UPDATE (ID NUMBER);

Table created.
SQL1> INSERT INTO T_UPDATE SELECT ROWNUM FROM DUAL CONNECT BY LEVEL < 4;

3 rows created.
SQL1> COMMIT;

Commit complete.
SQL1> SELECT * FROM T_UPDATE;
        ID
----------
         1
         2
         3
SQL1> UPDATE T_UPDATE SET ID = 4 WHERE ID > 2;

1 row updated.

在会话 2 发起 UPDATE 语句,更新 ID 大于 0 的记录,这时 UPDATE 操作由于会话 1 更新了 ID 为 3 的记录且未提交,会处于挂起状态:

SQL> SET SQLP 'SQL2> ' 
SQL2> UPDATE T_UPDATE SET ID = ID + 0.1 WHERE ID > 0;

然后在会话 3 插入一条新的记录,并提交:

SQL> SET SQLP 'SQL3> '
SQL3> INSERT INTO T_UPDATE VALUES (0.1);

1 row created.
SQL3> COMMIT;

Commit complete.

这时回到会话1,进行提交:

SQL1> COMMIT;
Commit complete.

检查会话 2,发现更新重启动发生,UPDATE 操作更新了 4 条记录:

4 rows updated.
SQL2> SELECT * FROM T_UPDATE;
        ID
----------
       1.1
       2.1
       4.1
        .2

会话 2 中不仅更新了之前存在的三条记录,连更新语句发起之后插入并提交的第四条记录也一起进行了更新,这说明更新重启动发生在第四条记录插入之后。

论坛里问题的时序和结果如下,大家也可以参考这个范例,理解更新重启动的含义:

image

这个案例很好的展示了更新重启动现象,不过这个帖子并没有完,除了这个更新重启动的案例外,还展示了一个另外一个案例,操作和这个案例仅有很小的差别,但是结果却大不相同。
案例2
首先把数据恢复到初始状态,在会话 2 回滚之前的更新:

SQL2> ROLLBACK;     

Rollback complete.

在会话1,恢复初始的数据情况,然后开始更新数据:

SQL1> DELETE T_UPDATE WHERE ID < 1;

1 row deleted.
SQL1> UPDATE T_UPDATE SET ID = 3 WHERE ID = 4;

1 row updated.
SQL1> COMMIT;

Commit complete.
SQL1> SELECT * FROM T_UPDATE;
        ID
----------
         1
         2
         3
SQL1> UPDATE T_UPDATE SET ID = 4 WHERE ID > 2;

1 row updated.

在会话 2,对表中所有的记录的 ID 执行 UPDATE 操作,和上一个案例的唯一差别是,这里没有使用 WHERE 语句:

SQL2> UPDATE T_UPDATE SET ID = ID + 0.1;

同样在会话3插入数据并提交:

SQL3> INSERT INTO T_UPDATE VALUES (0.1);

1 row created.
SQL3> COMMIT;

Commit complete.

回到会话1,进行提交:

SQL1> COMMIT;

Commit complete.

发现会话 2 仅更新了 3 条记录:

3 rows updated.

SQL2> SELECT * FROM T_UPDATE;
        ID
----------
       1.1
       2.1
       4.1
        .1

可以清晰的看到,最后一条插入的记录并未被更新,说明更新重启动并未被触发。
对比分析
为什么带有 WHERE 条件的更新操作触发了更新重启动,而不带 WHERE 条件的更新未触发重启动呢,我是这样理解的:当 UPDATE 操作包含了 WHERE 条件,那么这个查询的结果要满足 WHERE 定义的查询一致性,当更新发现一致性不满足的情况下,就会触发更新重启动。

而对于不包含 WHERE 条件或包含 WHERE 条件但是该条件与表查询无关的情况,这时 Oracle 的目标只是将表中所有的数据进行一次更新,并不需要考虑一致性的问题。因此,这个不加 WHERE 条件的 UPDATE,感觉其实现方式上类似这种通过 ORA_ROWSCN 限定来实现:

SQL2> ROLLBACK;

Rollback complete.

回到会话 1 恢复数据,并检查 ORA_ROWSCN 的值:

SQL1> DELETE T_UPDATE WHERE ID < 1;

1 row deleted.
SQL1> UPDATE T_UPDATE SET ID = 3 WHERE ID = 4;

1 row updated.
SQL1> COMMIT;

Commit complete.
SQL1> SELECT ID, ORA_ROWSCN FROM T_UPDATE;
        ID ORA_ROWSCN
---------- ----------
         1  231512964
         2  231512964
         3  231512964
SQL1> UPDATE T_UPDATE SET ID = 4 WHERE ID > 2;

1 row updated.

在会话 2,发起包含制定 ORA_ROWSCN 限制条件的更新:

SQL2> UPDATE T_UPDATE SET ID = ID + 0.1 WHERE ORA_ROWSCN = 231512964;

会话 3 插入并提交:

SQL3> INSERT INTO T_UPDATE VALUES (0.1);

1 row created.
SQL3> COMMIT;

Commit complete.

回到会话 1,进行提交:

SQL1> COMMIT;

Commit complete.

检查会话2:

3 rows updated.
SQL2> SELECT * FROM T_UPDATE;

        ID
----------
       1.1
       2.1
       4.1
        .1

采用 ORA_ROWSCN 的效果与直接 UPDATE 不带任何 WHERE 条件是一样的,说明更新只关注 UPDATE 语句发出时刻的数据,不再考虑整体更新结果的一致性问题。

关于更新重启动的更详细的描述,建议参考ASKTOM上的回复:
https://asktom.oracle.com/pls/apex/asktom.search?tag=write-consistency

原文发布时间为:2018-07-15
本文来自云栖社区合作伙伴“数据和云”,了解相关信息可以关注“数据和云”。

相关文章
|
7天前
|
SQL Oracle 关系型数据库
【Oracle】玩转Oracle数据库(一):装上去,飞起来!
【Oracle】玩转Oracle数据库(一):装上去,飞起来!
43 7
|
23天前
|
API 数据库 C语言
【C/C++ 数据库 sqlite3】SQLite C语言API返回值深入解析
【C/C++ 数据库 sqlite3】SQLite C语言API返回值深入解析
163 0
|
24天前
|
消息中间件 存储 数据库
RocketMQ 流数据库解析:如何实现一体化流处理?
RocketMQ 5.0 是一款云原生的消息中间件,旨在覆盖更多业务场景。它针对国内企业在数字化转型中面临的多场景消息处理需求,提供了一体化的解决方案。
111894 7
|
24天前
|
Oracle 关系型数据库 数据库
Oracle数据库基本概念理解(3)
Oracle数据库基本概念理解(3)
17 2
|
7天前
|
存储 中间件 关系型数据库
数据库切片大对决:ShardingSphere与Mycat技术解析
数据库切片大对决:ShardingSphere与Mycat技术解析
13 0
|
7天前
|
SQL Oracle 关系型数据库
【Oracle】玩转Oracle数据库(七):RMAN恢复管理器
【Oracle】玩转Oracle数据库(七):RMAN恢复管理器
31 5
|
7天前
|
存储 SQL Oracle
【Oracle】玩转Oracle数据库(二):体系结构、存储结构与各类参数
【Oracle】玩转Oracle数据库(二):体系结构、存储结构与各类参数
31 7
|
1月前
|
Oracle 关系型数据库 数据库
|
2月前
|
开发框架 Oracle 关系型数据库
ASP.NET实验室LIS系统源码 Oracle数据库
LIS是HIS的一个组成部分,通过与HIS的无缝连接可以共享HIS中的信息资源,使检验科能与门诊部、住院部、财务科和临床科室等全院各部门之间协同工作。 
35 4
|
1月前
|
关系型数据库 分布式数据库 数据库
PolarDB PostgreSQL版:Oracle兼容的高性能数据库
PolarDB PostgreSQL版是一款高性能的数据库,具有与Oracle兼容的特性。它采用了分布式架构,可以轻松处理大量的数据,同时还支持多种数据类型和函数,具有高可用性和可扩展性。它还提供了丰富的管理工具和性能优化功能,为企业提供了可靠的数据存储和处理解决方案。PolarDB PostgreSQL版在数据库领域具有很高的竞争力,可以满足各种企业的需求。

推荐镜像

更多