【说明】无意中看到一个同事的QQ留言上面写着“真累“，还没有过30分钟就接到这个同事的电话，如下：刚在做删除数据的时候，发现由于条件没有写好，导致删错了，有没有办法恢复；接到这个任务 ，首先是深深的感慨了一下：人在状态不好的情况下尽量多休息少做事，特别是涉及到很重要的事情。
跟着同事确定了出现问题的时间点后，先是安慰一下，让他从那惶恐不安的心里恢复过来，然后开始了找寻数据的工作。
【环境说明】
?数据库版本：11.2.0.3
?数据库闪回：未开启
【恢复步骤】
【1】确定用户删除数据的时间点和脚本，对于数据的恢复有很大的帮助，最好再对比下用户电脑上面的时间和服务器上面的时间差，查询的时候需要补上时间差(经检查服务器的时间和用户电脑的时间相差5分钟）
用户反馈客户端上面操作的时间时17:35分，但是服务器的时间落后用户的时间5分钟，所以查询脚本如下：
select * from t_original_archives as of timestamp to_timestamp('2015-11-17 17:30:00','YYYY-MM-DD HH24:MI:SS')? where? id=1974244
【2】把数据导出让用户进行检查
create table t_original_archives_bak as select * from t_original_archives as of timestamp to_timestamp('2015-11-17 17:30:00','YYYY-MM-DD HH24:MI:SS')? where id=1974244;
【3】确认没有问题后变可以把误删除的数据插入到原来的表中。
insert into t_original_archives select * from t_original_archives_bak
经过以上步骤，又一次拯救了一次数据灾难；
整个恢复的过程中对于误删除时间的控制最为重要，一般15分钟之内的数据库可以找到，超过15分钟的话要看天吃饭了。
以下是闪回查询的原理。
SQL>? show parameter undo;
NAME? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? TYPE? ? ? ? ? ? ? ? ? ? ? VALUE
------------------------------------ -----------? ------------------------------
_in_memory_undo? ? ? ? ? ? ? ? ? ? ? ? ? boolean? ? ? ? ? ? ? ? ? FALSE
undo_management? ? ? ? ? ? ? ? ? ? ? ? ? string? ? ? ? ? ? ? ? ? ? AUTO
undo_retention? ? ? ? ? ? ? ? ? ? ? ? ? ? ? integer? ? ? ? ? ? ? ? ? ? ? 900
undo_tablespace? ? ? ? ? ? ? ? ? ? ? ? ? ? string? ? ? ? ? ? ? ? ? ? UNDOTBS1
参数说明：
undo_management = auto，设置自动undo自动管理方式，默认设置为：auto；
undo_retention = n(秒),设置决定undo最多的保存时间，默认是900秒，建议条件允许的情况下可以设置多一些。
注意：并不是说系统一定会保留900秒的前镜像，也不是900秒后保留的前镜像就会消失，跟undo表空间的大小和系统的繁忙程度有关系。（一般情况15分钟之内的数据可以被查询得到的）
该参数的修改方式：SQL> alter system set undo_retention = 1800;
2、怎么保证undo存放的数据的存放时间？
方法：通过使用RETENTION GRARANTEE子句，保证数据库按照undo_retention的时间保留；
2.1 启动保证保留
ALTER DATABASE UNDOTBS01 RETENTION GUARANTEE
2.2 关闭撤销信息的保证保留
ALTER DATABASE UNDOTBS01 RETENTION NOGUARANTEE
3、启用RETENTION GRARANTEE的弊端
当启用了该参数后，业务繁忙的情况下，当undo表空间的使用率100%的情况下，数据库就会宕住，因为要保证undo的镜像不被覆盖，所以就不允许其他DDL语句的继续执行；
4、UNDO表空间大小的设定
方法1：可以根据AWR报告给出的建议来设置UNDO表空间的大小。
方法2：在业务系统高峰期的情况下，随时观察UNDO表空间的使用情况，进行调整。