Oracle闪回技术--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引入了一些数据表“伪列”，可以提供对数据版本的操作和检索。

工作心得：我师傅的师傅的师傅，流传给我们一句话：备份--备份---备份；备份永远最重要。但是我们很多人，工作的时间越久越胆小，主要是两个方面的原因：首先是备份的有效性，虽然有各种备份系统负责备份工作（特别是2012年以后，国内出现了很多国产的数据备份厂商），但是备份是不是有效一直是运维工程师心中的噩梦。第二个因素是恢复时间，大部分的Media Recovery都需要停机停服务，这对于7*24小时的高可用应用是不能允许的。另一方面，在现代企业级别数据中心环境下，如果存在正当的管理流程和方法，大规模数据恢复、回退的情况是比较少见的。

相应的，小规模数据恢复，如数据表一行数据被莫名误修改、数据表误删除等需要恢复的需求却不断增加。在传统的恢复技术中，这样粒度的恢复操作一般是不能支持的。

                                             申明：部分内容转载子其他博客。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/31480736/viewspace-2156043/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/31480736/viewspace-2156043/