在Oracle的Undo机制中，参数Undo_Retention扮演了“混淆者”的角色。论坛里面也有很多朋友对这个参数含义不是非常清楚。本篇我们就来讨论一下这个这个参数的含义和作用。

 

Oracle数据库 ORA-01555 快照过旧

用户user1对表进行了更新操作,用户user2在user1还没有进行提交前读表中数据,而且是大批量的读取(打个比方:耗时3分钟)而在这3分钟内user1进行了提交操作,那又会产生什么影响呢?这个时候怎么保证读写一致性呢?这个时候DBMS就要保证有足够大的undo表空间来存放修改前的数值,,以保证user2读取的数据是修改前的一致数据.然后下次再读取时候就是更新后的数据了.

ora-01555快照过旧就是因为undo空间不够大，其中一部分undo数据被覆盖了，用户无法获得修改前的数据。

undo数据分为三种：

活动的undo：未提交事务的undo数据，这些undo数据永远不能覆盖，用于回滚rollback事务。

过期的undo：已提交事务的undo数据，这些undo数据可以覆盖。

未过期的undo：事务已提交，但事务提交前，有些查询正在进行，它要读取的是提交前的数据，这部分数据就是未过期数据。如果这部分undo数据被覆盖了，就会发生ora-01555错误。

一个解决方法是，指定undo表空间参数UNDO_TABLESPACE，并将undo空间管理方法设置成自动扩展：UNDO_MANAGEMENT=AUTO。

这种方法可能产生的结果是：

因为undo表空间装了太多未过期（unexpired）的undo数据，新的transaction无法向其中写入undo数据，这时transaction就会发生ORA-30036错误。

 

1、从Undo说起

Undo或者说rollback segment机制是Oracle早期奠定行业地位的核心技术之一。Undo机制的提出，源自于Oracle提出的“多版本一致读”特性。在Oracle中，select操作不会阻塞任何操作，也不会被任何操作所阻塞。

 

这就意味着，当我们对一个数据表进行DML操作，比如插入、修改和删除数据的时候，其他会话连接的select操作是可以随意进行的，而且访问的数据都是DML操作之前提交的数据。

 

Oracle数据是保存在“表空间、段对象、分区和数据块”的组织结构体系中。对数据的修改就是在数据块中直接的修改。如果需要同时支持对之前数据的访问，比如在系统中有一个地方需要保存数据的“前镜像pre-image”,同时一旦DML进行回滚rollback动作，恢复数据也需要这部分前镜像内容。这就衍生出了rollback segement和之后的Undo表空间。

 

严格的说，多版本一致读是两个Oracle特性。一致读所说的是：当一个查询读操作select数据的时候，只能读取到小于等于启动查询操作时候SCN的数据。比如：我们启动查询的时候，数据表A中包括10亿条数据。之后另一个会话启动删除了1亿条数据并且提交。提交之后，第一个读会话才检索到原来1亿条数据的位置，并且最后结束。从结果看，第一个会话读取到的是10亿条数据。一致读特性的关键就在于保证了读操作的一致性，读取数据在时间层面的一致性。细想一下，第二个会话commit之后，源数据1亿条的前镜像在Undo空间中是失效Expired状态。一致读过程中，一定是进行过失效Undo镜像数据的读取。

 

失效Undo数据的最终归宿是被覆盖重用。想想一种情况，如果系统中Undo管理比较不合理，事务Undo数据量比较大而且频繁，有失效的Undo前镜像被覆盖之后，恰恰有一个长时间查询需要访问这个前镜像。这个时候，Oracle就只能说“抱歉”了，这也就是经典的ora-1555 snapshot too old的起源。

 

Undo失效数据的另一种用途就是Flashback闪回。Flashback Query和Flashback Archive都是建立在对前镜像数据再利用处理上。

Undo_Retention是Oracle提供出的用于控制Undo过期数据保留的“调节Tune”参数。注意：这里不是控制参数。Oracle中的控制参数起到强制作用，比如目录空间位置，归档文件存储等。但是另一部分参数起到的是目标调节的作用，比如检查点间隔控制，SGA_TARGET。

SQL> show parameter undo;

NAME             TYPE  VALUE
------------------------------------ ----------- ------------------------------
undo_management          string  AUTO
undo_retention           integer   900
undo_tablespace          string  UNDOTBS3

undo_retention从直接看就是设置Oracle Undo过期数据的保存期限，单位是秒。如果参数设置为900秒，那么Undo段数据在非Active状态之后，会保留900秒。

 

如果根据这个守则，我们进行一致读和Flashback的时间就是通过这个参数来进行控制的。但是事实上，这个是有问题的。Undo的覆盖动作是一个必然的过程，覆盖与否是要和系统事务Undo消耗速率、Undo Tablespace大小乃至Undo数据文件可拓展性密切相关。

 

事实上，Undo_retention是一个“目标期望值”。用户设置出这个值之后，Oracle内部会尽量保证将Undo数据保留超过undo_retention设置的时间。在这个过程中，Oracle会涉及到比如尝试拓展Undo表空间数据文件、Undo Segment管理等内容。但是，如果“现实比较残酷”，比如说Undo使用紧张、没有额外的方法，那么这个时间段也是不能保证的。

 

下面我们通过一系列的实验来验证。

 

2、环境准备

SQL> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
PL/SQL Release 11.2.0.4.0 - Production
CORE  11.2.0.4.0  Production
TNS for Linux: Version 11.2.0.4.0 - Production
NLSRTL Version 11.2.0.4.0 - Production

当前采用自动的undo管理机制，默认retention为900秒。注意：这个取值Oracle是有所选择的。早期版本中曾经设置过1800秒。
SQL> show parameter undo;

NAME             TYPE  VALUE
------------------------------------ ----------- ------------------------------
undo_management          string  AUTO
undo_retention           integer   900
undo_tablespace          string  UNDOTBS3

当前undo tablespace的数据文件拓展情况为支持拓展，容量为100M。
SQL> col FILE_NAME for a30;
SQL> set linesize 1600;
SQL> select FILE_NAME,BYTES/1024/1024 "bytes",MAXBYTES/1024/1024 "maxbytes",AUTOEXTENSIBLE from dba_data_files 
  2  where TABLESPACE_NAME='UNDOTBS3';

FILE_NAME         bytes   maxbytes AUT
------------------------------ ---------- ---------- ---
/u01/app/oracle/oradata/oradb/        100  32767.9844 YES
undotbs03.dbf


3、超过undo_retention情况数据读取
在没有强制的Undo数据覆盖情况下，Oracle默认会一直保留前镜像的数据。在实际中，虽然undo_retention设置的保留值比较小，但是我们依然可以flash back query出几个小时乃至几天前的数据。
为了便于实验过程，我们调节了一下参数。
SQL> alter system set undo_retention=300;

System altered.
SQL> show parameter undo_retention;

NAME             TYPE  VALUE
------------------------------------ ----------- ------------------------------
undo_retention           integer   300

此处我们使用的是较大的Undo表空间100M，而且支持自动拓展文件。实验数据表情况如下：
SQL>  create table t as select * from dba_objects;

Table created.

SQL> select bytes/1024/1024 MB from dba_segments where OWNER='SYS' and segment_name='T';

  MB
----------
 1.5390625

SQL> select count(*) from t;  --注意：当前时点上，数据量为1万。

  COUNT(*)
----------
     13524
SQL> select sysdate from dual;

SYSDATE
------------
21-DEC-18

删除数据前查一下系统时间
[root@Database2 ~]# date
Fri Dec 21 13:24:12 CST 2018
删除数据
SQL> delete t; 

13524 rows deleted.

SQL> commit;

Commit complete.

经过十五分钟左右，注意这个时间已经远远超过900秒设置值。
[root@Database2 ~]# date
Fri Dec 21 13:37:28 CST 2018

SQL> select count(*) from t as of timestamp to_timestamp('2018-12-21
13:24:12','yyyy-mm-dd hh24:mi:ss');  2  

  COUNT(*)
----------
     13524

超过了900秒，Undo前镜像依然保留而且可以访问到。到此我们可以得出结论，即使commit后超过了undo_retention设置的时间范围，前镜像数据依然可以读取到。