闪回是oracle恢复革命性的功能，相对于不完全恢复，它有着快速简单的特点，缺点是仅可以处理逻辑，对于像数据文件删除等物理错误不可处理（表空间删除之后controlfile里面对表空间的记录也消失，因此不能闪回）。闪回flashback的反义词是恢复recover。
Flashback Database 功能非常类似与RMAN的不完全恢复， 它可以把整个数据库回退到过去的某个时点的状态， 这个功能依赖于Flashback log 日志。 比RMAN更快速和高效。 因此Flashback Database 可以看作是不完全恢复的替代技术。 但它也有某些限制：
1. Flashback Database 不能解决Media Failure， 这种错误RMAN恢复仍是唯一选择
2. 如果删除了数据文件或者利用Shrink技术缩小数据文件大小，这时不能用Flashback Database技术回退到改变之前的状态，这时候就必须先利用RMAN把删除之前或者缩小之前的文件备份restore 出来， 然后利用Flashback Database 执行剩下的Flashback Datbase。
3. 如果控制文件是从备份中恢复出来的，或者是重建的控制文件，也不能使用Flashback Database。
否则有报错“ORA-38727: FLASHBACK DATABASE 需要当前的控制文件。”
4. 使用Flashback Database锁能恢复到的最早的SCN， 取决与Flashback Log中记录的最早SCN。
Flashback Database 架构
Flashback Database 整个架构包括一个进程Recover Writer(RVWR)后台进程，Flashback Database Log日志 和Flash Recovery Area。一旦数据库启用了Flashback Database， 则RVWR进程会启动，该进程会向Flash Recovery Area中写入Flashback Database Log， 这些日志包括的是数据块的 " 前镜像(before image)"， 这也是Flashback Database 技术不完全恢复块的原因。
应用的前提条件
a，归档模式
b，flashback_on启动
SYS@jsce>select flashback_on from v$database;
FLASHBACK_ON
------------------
NO
show parameter retention--1440分，即一天
用户对表数据的修改操作，都记录在撤销表空间中，这为表的闪回提供了数据恢复的基础。例如，某个修改操作在提交后被记录在撤销表空间中，保留时间为900秒，用户可以在这900秒的时间内对表进行闪回操作，从而将表中的数据恢复到修改之前的状态。
问：如果这900s内没有操作其他的，是不是可以更长？
v$flashback_database_log可以看闪回多久
一、闪回数据库
查询当前的scn
SYS@ncbeta>select current_scn from v$database;
CURRENT_SCN
-----------
3625299
删除scott下的emp表 --ddl语句本身就 隐含了commit，drop table 不需要commit
闪回数据库，找回emp
报错，需要mount下（基本所有的数据恢复都需要mount下）
SYS@ncbeta>flashback database to scn 3625299;open之后需要resetlogs
闪回到时间：
Flashback database to timestamp to_timestamp('12-01-13 15:26:34','yy-mm-dd hh24:mi:ss');
scoot的emp恢复
补充：scn和time的转换可以如下操作：
SYS@ncbeta>Select to_char(scn_to_timestamp(3625299),'YYYY-MM-DD HH24:MI:SS') from dual;
TO_CHAR(SCN_TO_TIME
-------------------
2013-01-21 11:10:54
二、闪回表 此操作不需要mount
原理：恢复来自undo_tablespace
首先要启动表的行移动特性
SCOTT@ncbeta>select ROW_MOVEMENT from user_tables where table_name='EMP';
ROW_MOVE
--------
DISABLED
SCOTT@ncbeta>alter table emp enable row movement;
表已更改。
sys下找到现在数据库的scn： 3632069
对emp表进行insert操作--14行变成15行，xs是新加入
后来发现错误，闪回表--闪回确实快
SCOTT@ncbeta>flashback table emp to scn 3632069;
闪回表需要考虑的事情
1. FLASHBACK TABLE命令作为单一的事务执行，会得到一个单一的DML锁
2. 表的统计数据不会被闪回
3. 当前的索引和从属的对象会被维持
4 系统表不能被闪回
5 不能跨越DDL操作
6 会被写入警告日志
7 产生撤销和重做的数据
比如2统计数据，user_tables 有一个NUM_ROWS字段，在insert表之后，统计的和总数对应不上
使用analyze分析之后，可以解决这个问题
SCOTT@ncbeta>analyze table emp compute statistics;
对于删除表，可以使用to before drop来闪回
SCOTT@ncbeta>flashback table emp to before drop;
在闪回模式打开之后，删除的操作在闪回区都有放映 --需要回滚段满了之后才会更新
删除的表在回车站，被改名，如果要彻底删除可以使用drop table xx purge
三、闪回版本查询（查询变化）
闪回查询只能查看到特定时间点的表中的数据，但不能完整地查看到在两个时间点之间表中数据的变化情况。而闪回版本查询就提供了这样的功能，它提供来一个审计各个行的数据改变的功能，它能找到所有已经提交了的操作及其操作时间、结果。所以闪回版本查询在某种程度上可以替代精细审计功能和LogMiner工具的功能。
只要是在撤销段中现有的数据都可以被用于闪回版本查询。因此，最大可用的版本依赖于undo_retention初始化参数的设置。由于该参数不是强制性的，所以如果想保证在该参数所设置的时间内不会覆盖撤销段中已经提交的数据，就需要给撤销表空间设置RETENTION GUARANTEE选项。
可以查询一段时间内字段的变化，比如应用于股票
首先在scott下面查询当前scn
SCOTT@ncbeta>select timestamp_to_scn(SYSTIMESTAMP) as scn from dual;
SCN
----------
3634862
这个时候
EMPNO ENAME SAL
------ ---------- ----------
22 xs 8000
之后update
select sal, versions_starttime, versions_endtime, versions_xid, versions_operation from emp versions 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空间的不足而报一个错而推出。
1、先解释下undo_retention
设置undo_retention，保证commit 后的数据在undo segment中保留多长时间。但是并不能保证commit后的undo 信息在undo_retention的时间内一定不被覆写，当undo segment不够时，还是会覆盖已commit的undo 信息。
alter tablespace undotbs2 retention guarantee;
撤销该参数
alter tablespace undotbs2 retention noguarantee;
select sal,ename, versions_xid
from emp versions between scn minvalue and maxvalue
where empno = '22';
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' and table_name='EMP';
undo_sql: update "SCOTT"."EMP" set "SAL" = '5600' where ROWID = 'AAAR3sAAEAAAACTAAB';--变为原来的5600
