3、Versions between版本查询
功能更加强大，通过versions between能够查看指定时间段内undo表空间中记录的不同版本（注意，只包括被提交的记录）。
版本查询的用法并不比as of复杂，与其类似，你只需要在标准查询后面附加versions between timestamp[/scn] t1 and t2即可。记录在版本查询中可能会是一对多的关系，比如某些记录如果被修改过多次，并分别提交，那么你在查询的时候，如果修改的操作是在你指定的时间段(或scn)，则记录每次修改的结果都会被选择出来，这比较有利于我们做数据的对比，比如看看数据究竟是怎么变化的。
版本查询过程中提供了多个伪列如下：
| VERSIONS_STARTSCN VERSIONS_STARTTIME |
该记录操作时的scn或时间，如果为空，表示该行记录是在查询范围外创建的。 |
| VERSIONS_ENDSCN VERSIONS_ENDTIME |
该记录失效时的scn或时间，如果为空，说明记录当前时间在当前表内存在，或者已经被删除了，可以配合着VERSIONS_OPERATION列来看，如果VERSIONS_OPERATION列值为D，说明该列已被删除，如果该列为空，则说明记录在这段时间无操作。 |
| VERSIONS_OPERATION |
对该行执行的操作：I表示insert，D表示delete，U表示update。 提示：对于索引键的update操作，版本查询可能会将其识别成两个操作：DELETE和INSERT。 |
| VERSIONS_XID |
该操作的事务ID |
操作实例：(结果事例就不贴了)
| SQL> select v_id,va,versions_startscn,versions_endscn,versions_operation from t_fb_test versions between scn 12372466 and 12372538 order by 1; |
根据结果返回，每个记录各有两个版本，一行的VERSIONS_STARTSCN和VERSIONS_OPERATION有值，记录了开始时的SCN和执行的操作，另一行则是VERSIONS_ENDSCN有值，记录了该版本失效时的scn。
从VERSIONS_OPERATION列可以看出操作是：I表示insert，D表示delete，U表示update。
4、Transaction query事务查询
Flashback的事务查询是通过查询flashback_transaction_query视图来实现的。通过查询该视图能够获得一些事务执行时的信息，甚至包括UNDO语句。
| select xid,commit_scn,commit_timestamp,operation,undo_sql from flashback_transaction_query q where q.xid in( select versions_xid from t_fb_test versions between scn 23413946 and 23413959); |
上述的查询结果已经清晰的向我们展示了我们所做的操作以及操作的时间等(实际执行的语句该视图并没有记录，只能通过undo_sql和operation推测)，随着我们将事务范围的不断扩大，我们可以持续向前翻阅曾经做过的操作。当然，实际使用的时候需要注意，由于该视图存储记录量较大(究竟有多大呢，目前尚未找到相关文档有明确说明，初步预计，应该与smon_scn_time的存储规则有关系)，查询的时候建议通过关键列过滤，比如logon_user啦，table_name或table_owner之类的，这么比起来这项操作倒确实与logminer非常想像，这简直就是个活的logminer啊，虽然只是一段时间内的。
5、制约因素
制约该特性应用的有三方面的因素
5.1 自动撤销管理表空间
这个是前面也提到了，要使用flashback的相关特性，必须启用自动撤销管理表空间，不仅是flashback query,也包括flashback table和flashback database，而对于后两项还会有些其它的附加条件，比如flashback table需要启用了recycle bin(回收站)，flashback database还要求必须启用了flashback area(闪回区)。
5.2 初始化参数
初始化参数UNDO_RETENTION的设置严格说起来也是与undo表空间有关系，但是思量再三，我觉着还是有必要单拎出来详细介绍。
该参数用来指定undo记录保存的最长时间，以秒为单位，是个动态参数，完全可以在实例运行时随时修改通常默认是900秒，也就是15分钟。
一定要注意，undo_retention只是指定undo数据的过期时间，并不是说，undo中的数据一定会在undo表空间中保存15分钟，比如说刚一个新事务开始的时候，如果undo表空间已经被写满，则新事务的数据会自动覆盖已提交事务的数据，而不管这些数据是否已过期，因此呢，这就又关联回了第一点，当你创建一个自动管理的undo表空间时，还要注意其空间大小，要尽可能保证undo表空间有足够的存储空间。
同时还要注意，也并不是说，undo_retention中指定的时间一过，已经提交事务中的数据就立刻无法访问，它只是失效，只要不被别的事务覆盖，它会仍然存在，并可随时被flashback特性引用。如果你的undo表空间足够大，而 数据库又不是那么繁忙，那么其实undo_retention参数的值并不会影响到你，哪怕你设置成1(这么说好像绝对了点，大家一定要注意理解，表钻牛角尖)，只要没有事务去覆盖undo数据，它就会持续有效。因此呢，这里还是那句话，要注意undo表空间的大小，保证其有足够的存储空间。
5.3 DDL操作的影响
第三个就是修改并提交过数据之后，对表做过DDL操作，包括：
drop/modify列, move表, drop分区(如果有的话), truncate table/partition，这些操作会另undo表空间中的撤销数据失效，对于执行过这些操作的表应用flashback query会触发ORA-01466错误。另外一些表结构修改语句虽然并不会影响到undo表空间中的撤销记录，但有可能因表结构修改导致undo中重做记录无法应用的情况，比如对于增加了约束，而flashback query查询出的undo记录已经不符合新建的约束条件，这个时候直接恢复显然不可能成功，你要么暂时disable约束，要么通过适当逻辑，对要恢复的数据进行处理之后，再执行恢复。
另外，flashback query对v$tables,x$tables等动态性能视图无效，不过对于dba_*,all_*,user_*等数据字典是有效的。同时该特性也完全支持访问远端数据库，比如select * from tbl@dblink as of scn 360;的形式。