今天提交给客户方一个sql脚本去跟新历史数据，结果客户那边的部署人员犯了一个错误，直接拿系统账号去部署，结果第一段代码没有执行成功，结果第二段代码却执行成功了，并且已经提交了的，。。。。由于事前没有备份第二段更新表的数据，导致恢复标的数据非常困难，网上查找了半天，现在将找到的办法归纳如下：
1. 执行如下SQL将test_temp表中的数据恢复到2016年7月7号，即脚本被执行之前时间点。
注意，这里一定要先删除全部数据，否则可能会导致数据重复
1 SELECT * FROM DQAQTSW
2 AS OF TIMESTAMP TO_TIMESTAMP('2016-07-07 00:00:00',
3 'yyyy-mm-dd hh24:mi:ss');
|
1
2
3
4
5
|
delete from test_tmp;
insert into test_tmp select *
from test_tmp as of timestamp to_timestamp('2014-05-28 11:00:00','yyyy-mm-dd hh24:mi:ss')
commit;
|
或者得到sync的节点时间，基本和第一种方法是一致的。
1 select timestamp_to_scn(to_timestamp('2014-05-27 11:00:00','YYYY-MM-DD HH:MI:SS'))
2 from dual;
3 或 select * from sys.smon_scn_time order by time_dp desc;
4 得到结果 71547785 然后
5 insert into test_tmp select * from test_tmp AS OF SCN 71547785
注意：
truncate后的数据是无法恢复的
truncate table test_temp;
2. 下面看第三种（这种方法需要更高的管理权限，否则没法查询回复数据）
|
1
2
3
4
|
select * from v$sqlarea ;
SELECT * FROM v$session;
SELECT * FROM v$session a,v$sqlarea b
WHERE b.ADDRESS = a.PREV_SQL_ADDR;
|
通过这条语句找到的数据是有限的 因为有的用户可能已经断开和oracle的连接了
如果你看到以上方法能够解决你的问题，哪就不要犹豫，快点动 手吧，因为如果动手晚了，之前的操作的数据记录可能就要被覆盖了，因为存储不大的话要被循环使用的