在生产当中，需要做恢复数据的场景还算是相当少的，特别大的恢复场景，比如整个数据库的恢复，或者是这个表空间的恢复，
这些少之又少。不过，表级数据的恢复还是时不时会遇到的，比如有些业务人员或者维护人员修改错误的数据做了提交，或者
不小心把某条数据删除了。遇到这种情况，首先不要急，得要把问题搞清楚，不要急着去做恢复数据，一不小心，可能连dba
都采取了错误的恢复方法，那就麻烦了，反而越帮越忙了。
最近几天，我自己也遇到几次这种情况：业务人员反映，误删除了一条数据，现在又想要回来那一条数据，还有就是update一条数据记录
的时候忘记带上where条件，导致了表中所有的记录的同个字段的值相同，commit了才发现更新时忘记带上条件了。错误删除整张表的数据或者
truncate整张表的情况倒是还没有遇到。
生成当中，一般都会开启闪回恢复功能，在这个的基础上，我们根据删除数据的多少情况去选择哪一种方法来恢复。当然，如果是使用闪回方法
做恢复，还有一个就是undo表空间有足够的回滚数据块。一下各种情况，个人的建议方法：

1、删除一条或者多条记录，或者错误多条数据，应该采用闪回查询技术的方法来恢复：
insert into suxing.ins_771
select t.* from suxing.ins_771 as of timestamp(sysdate-1/24) t where user_id='4877';
或者：
update suxing.ins_771 set ID=
（select ID from suxing.ins_771 as of timestamp(sysdate-1/24) where user_id='4877'）;
如果是整个表的同个字段都修改错了，需要通过闪回查询创建一个中间表，准备在更新回更新前的数据使用。

2、删除整个表的时候：

flashback table "BIN$PafEvIK1PW/gUwEAAH/iiQ==$0"
2 to before drop rename to test11;
#该处的新表表名test11可以与原表名相同，只要恢复时候原来表名不被占用。

3、注意，在第1种的情况下，直接把表闪回到某个时间戳是存在风险的。要知道，在生产当中，可能存在多个人在你操作失误
之后多次使用同样的表，不同的记录，这种情况，直接做表闪回，逻辑是不够严密的。除非，在你出错之后的一段的时间，没有其他人
再修改过这个表，可以直接使用以下语句做恢复：
flashback table test1 to timestamp
2 to_timestamp('2016-09-29 22:20:37','yyyy-mm-dd hh24:mi:ss');

ITPub博客

闪回恢复一个表中的数据

最新文章