今天提交给客户方一个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‘);
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. 下面看第三种(这种方法需要更高的管理权限,否则没法查询回复数据)
select * from v$sqlarea ; SELECT * FROM v$session; SELECT * FROM v$session a,v$sqlarea b WHERE b.ADDRESS = a.PREV_SQL_ADDR;
通过这条语句找到的数据是有限的 因为有的用户可能已经断开和oracle的连接了
如果你看到以上方法能够解决你的问题,哪就不要犹豫,快点动 手吧,因为如果动手晚了,之前的操作的数据记录可能就要被覆盖了,因为存储不大的话要被循环使用的
(以上博客很多引用来自 http://vvv-110.iteye.com/blog/2072702 )
时间: 2024-11-05 10:36:56