工作时间越长,胆子其实就是越小。很多很多时候,有备份并不意味着可以高枕无忧。这种论断主要是基于两方面的因素,其一是备份的有效性,虽然有各种工具系统介质负责备份工作,但是备份是不是有效一直是运维工程师心中的噩梦。第二个因素是恢复时间,大部分的Media Recovery都需要停机停服务,这对于7*24小时的高可用应用是不能允许的。另一方面,在现代企业级别数据中心环境下,如果存在正当的管理流程和方法,大规模数据恢复、回退的情况是比较少见的。
相应的,小规模数据恢复,如数据表一行数据被莫名误修改、数据表误删除等需要恢复的需求却不断增加。在传统的恢复技术中,这样粒度的恢复操作一般是不能支持的。
从10g开始,Oracle开始大面积引入“Flashback”技术,或者成为Flashback技术工具集合,来提供多级别多粒度的“逻辑恢复”。经过若干年的发展,Flashback家族已经有诸多的分支技术,依托不同的技术技术,来实现多粒度的数据恢复。在笔者之前的文章中,已经陆续介绍了一些Flashback技术和应用,本篇继续介绍Flashback Version Query。
1、环境介绍
笔者选择Oracle 11g进行测试,具体版本为11.2.0.4。
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
Flashback Version Query的配置基础和Flashback Query相同,都需要启用Automatic Undo Management,通过Undo_Retention进行控制时间长短。
SQL> show parameter undo
NAME? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? TYPE? ? ? ? VALUE
------------------------------------ ----------- ------------------------------
undo_management? ? ? ? ? ? ? ? ? ? ? string? ? ? AUTO
undo_retention? ? ? ? ? ? ? ? ? ? ? integer? ? 900
undo_tablespace? ? ? ? ? ? ? ? ? ? ? string? ? ? UNDOTBS1
为了实验方便,调整undo_retention到1800。
SQL> alter system set undo_retention=1800 scope=both;
System altered
SQL> show parameter undo_re
NAME? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? TYPE? ? ? ? VALUE
------------------------------------ ----------- ------------------------------
undo_retention? ? ? ? ? ? ? ? ? ? ? integer? ? 1800
创建实验数据表。
SQL> create table test as select empno, ename, sal from scott.emp where rownum<3;
Table created
SQL> commit;
Commit complete
SQL> select * from test;
EMPNO ENAME? ? ? ? ? ? SAL
----- ---------- ---------
?7369 SMITH? ? ? ? 800.00
?7499 ALLEN? ? ? ? 1600.00
2、Flashback Version Query
Flashback Version Query和Flashback Query从技术基础上,都是相似的,也就是借助Oracle的Undo机制。作为一款成功的数据库产品,Undo和Redo机制是Oracle最核心的技术。Undo记录的是数据DML操作的前镜像,经典的Oracle事务模型中,一旦事务被commit,理论上之后SCN启动的读操作都不能读到之前的镜像数据。
Oracle于是利用Undo的机制,提供了短时间内的数据表旧版本查询。通过as of {timestamp | scn}指定时间点,就可以进行查询。当然,这个旧版本时间并不是无限长度,这就涉及到undo_retention这个争议参数。
很多朋友都不是很理解undo_retention,这个以秒为单位的参数经常让人很抓狂。官方理解是:设置undo_retention之后,可以支持设置秒数的闪回数据查询。但是在实际工作中,却发现很多时候超过这个时间的数据也能检索到,但是有的时候没有到这个时间间隔旧版本数据,也不能找到。
其实,Undo_retention参数其实是用户建议Oracle数据库的一个“建议理想值”。试想一下,Undo数据是一个不断循环覆盖使用的空间,旧Undo前镜像一定会被新Undo前镜像覆盖。事务负载不同的系统,对Undo的使用情况也是不同的。
如果Undo_Retention保留的时间比较长,而恰恰数据库系统是一个事务操作频繁的系统,那么Oracle如果想要坚持undo_retention,就必须维持一个比较大可拓展的Undo Tablespace。这时候,如果恰恰Undo Tablespace的文件被设置为不可拓展的,那么Oracle也就不能保证undo_retention的理想值了。
参数retention grantee是设置在undo tablespace的参数设置。如果设置了这个参数,就表示Oracle一定要保证undo_retention的理想设置值,即使不能完成事务过程。
Flashback Query和Flashback Version Query,都是依赖Undo过期数据的来构建前镜像的操作。
与Flashback Query不同的是,Flashback Version Query引入了一些数据表“伪列”,可以提供对数据版本的操作和检索。下面通过一个SQL来查看。
SQL> select versions_xid xid, versions_startscn start_scn, versions_endscn endscn, versions_operation operation, empno from test versions between scn minvalue and maxvalue;
XID? ? ? ? ? ? ? START_SCN? ? ENDSCN OPERATION EMPNO
---------------- ---------- ---------- --------- -----
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 7369
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 7499
数据表test,显然没有诸多的列定义。从这个情况看,flashback query提供了一种数据行