只要是在撤销段中现有的数据都可以被用于闪回版本查询。因此，最大可用的版本依赖于undo_retention初始化参数的设置。由于该参数不是 强制性的，所以如果想保证在该参数所设置的时间内不会覆盖撤销段中已经提交的数据，就需要给撤销表空间设置RETENTION GUARANTEE选项。

可以查询一段时间内字段的变化，比如应用于股票

首先在scott下面查询当前scn

SCOTT@ncbeta>select timestamp_to_scn(SYSTIMESTAMP) as scn from dual;

SCN

----------

3634862

这个时候

EMPNOENAME SAL

------ ---------- ----------

22xs 8000

之后update

select sal,

versions_starttime,

versions_endtime,

versions_xid,

versions_operation

from empversions between scn 3636070 and 3636113

where empno = '22';

测试时出现“ORA-30052: 下限快照表达式无效”错误，原因是指定的时间范围不在 UNDO_RETENTION 的撤销范围内（比如说你指定了是2小时之前的时间，

而 UNDO_RETENTION < 7200）。

备注：关于undo_retention和retention guarantee

undo_retention参数的作用是用来控制当transaction被commit后，undo信息的 保留时间。这些undo信息可以用来构造consistent read以及用于一系列的闪回恢复，而且足够的undo信息还可以减少经典的ORA-01555 Snapshot too old（快照太旧，长时间查询过程中还未过期的撤销数据已被覆盖造成）。这个参数的默认值为900（秒），这是一个noguarantee的限制，也就是 说我将undo_retention=900,原本以为在一个事务提交后，之前的撤销数据还可以保存900秒才可以被别的事务覆盖，殊不知当有其他的事务处理过程中需要undo空间的时候，恰恰这个时候undo表空间没有足够的空间了，而且我们没有开启自动扩展，且由于我们的retention是 noguarantee的，所以事务就会忽略这种retention的时间限制而直接覆盖我们的undo信息，这种结果下其实在很多情况下是不希望看到的。 Oracle 10g后新增了一个参数guarantee，可以强制oracle来保护undo信息，也就是说即使新的事务需要undo空间的时候，即使undo的空间 不足，这个session也不会强制覆盖由undo_retention所保护的undo信息，而且这个新增事务会因为undo空间的不足而报一个错而推 出。

10g 中RETENTION GUARANTEE 的作用 :

1、先解释下undo_retention

设置undo_retention，保证commit 后的数据在undo segment中保留多长时间。但是并不能保证commit后的undo 信息在undo_retention的时间内一定不被覆写，当undo segment不够时，还是会覆盖已commit的undo 信息。

2、如果需要保证在undo_retention时间内undo 信息一定不被覆写的话，可以对undo segment设置RETENTION GUARANTEE。但是这个参数受到undo_retention和undo size的限制。如果undo size 太小，undo_retention设置太久，设置retention guarantee 时就会报错：

ORA-30036: unable to extend segment by 8in undo tablespace 'UNDOTBS2'

3、设置该参数

altertablespace undotbs2 retention guarantee;

撤销该参数

altertablespace undotbs2 retention noguarantee;

2013-01-22 14:50:45更新：

update操作之后需要commit，写入redo log， 系统才能识别

select sal,ename, versions_xid

from emp versions between scn minvalue and maxvalue

where empno = '22';

四、闪回事务查询

闪回事务查询其实是闪回版本查询的扩充或继续。它提供了一种查看事务级数据库变化的方法。通常需要首先借助闪回版本查询查出其事务版本号，然后再进行闪回事务的查询。

flashback_transaction_query

select sal,ename, versions_xid

from emp versions between scn minvalue and maxvalue

where empno = '22';

发现更新错误，通过xid查询sql及undo sql

select xid, start_scn, to_char(start_timestamp, 'yyyy-mm-dd hh24:mi:ss')starttime, undo_sql

from flashback_transaction_query where xid='06000200F2060000' andtable_name='EMP';

undo_sql: update "SCOTT"."EMP" set"SAL" = '5600' where ROWID = 'AAAR3sAAEAAAACTAAB';--变为原来的5600