oracle10g闪回恢复数据表---前任公司

author:skate

time :2009-03-17 12:11:08



今天早晨8点多接到一个电话，是前任公司的老总的；迷迷糊糊的听他说，有人昨晚21点多误操作数据库，用update
更改表的数据，而没有加where条件，致使整个表都被更改了，让我帮他恢复下，毕竟曾经工作过，虽然我的保险到
现在没有给我，当我还是答应帮看看。我记得那个数据库有exp文件，可以通过这个来恢复



我让他先把emp文件给backup一份，免得被覆盖了，我洗漱之后来到公司，管前任公司要了远程登录权限，登录上去
看看，一看exp文件正好是昨天早上的，他的那个表一般更新也很少，应该够用了；但那的需要多长时间啊！！！
因为从昨天晚上到现在已经有12个小时了，但我还是试试用oracle10g的flashback来看看，结果select一看，还没
被覆盖，想要的数据还在，于是对其简单的恢复到误操作前的时间

误操作前的表：

MOVO_NEW at omovo> select * from COMPASSTEMPLET as of timestamp to_timestamp('2009-03-16 20:00:00','yyyy-mm-dd hh24:mi:ss');

COMPASSTEMPLETID COMPASSID TEMPLETBASEID REMARK1 REMARK2
---------------- ---------- ------------- -------------------------------------------------- --------------------------------------------------
207 181 43
229 203 43
427 903 4
447 924 4
467 943 4
627 1124 4
887 1423 4
927 1503 4
307 763 63
308 764 64
327 803 4
347 823 83
367 843 103
390 867 64
607 1109 4
647 1143 4
707 1243 4
747 1283 4
828 1364 4
388 865 83
389 866 103
391 868 63
392 869 41
408 886 64
487 963 4
567 1083 4
727 1263 4
808 1344 4
827 1363 4
847 1383 4
47 45 6
48 46 5
102 76 4
103 77 4
49 47 7
3 3 1
53 51 4
85 55 4
141 115 4
146 124 4
1 1 8
2 2 2
38 38 3
101 75 4
12 43 3
45 44 3
54 52 4
84 42 11
86 56 9
104 78 11
143 118 10
144 119 9
169 148 21
185 160 41
50 48 4
55 53 2
121 95 12
187 161 4
228 202 4
247 221 4
267 342 4
287 703 4
407 883 4
507 983 4
527 1043 4
568 1084 4
667 1164 4
748 1284 4
787 1323 4
867 1403 4
907 1483 4
909 1485 4
547 1063 4
587 1106 4
687 1205 4
767 1303 4
807 1343 4

77 rows selected.

误操作后的表：

MOVO_NEW at omovo> select * from COMPASSTEMPLET as of timestamp to_timestamp('2009-03-16 22:00:00','yyyy-mm-dd hh24:mi:ss');

COMPASSTEMPLETID COMPASSID TEMPLETBASEID REMARK1 REMARK2
---------------- ---------- ------------- -------------------------------------------------- --------------------------------------------------
207 181 64
229 203 64
427 903 64
447 924 64
467 943 64
627 1124 64
887 1423 64
927 1503 64
307 763 64
308 764 64
327 803 64
347 823 64
367 843 64
390 867 64
607 1109 64
647 1143 64
707 1243 64
747 1283 64
828 1364 64
388 865 64
389 866 64
391 868 64
392 869 64
408 886 64
487 963 64
567 1083 64
727 1263 64
808 1344 64
827 1363 64
847 1383 64
47 45 64
48 46 64
102 76 64
103 77 64
49 47 64
3 3 64
53 51 64
85 55 64
141 115 64
146 124 64
1 1 64
2 2 64
38 38 64
101 75 64
12 43 64
45 44 64
54 52 64
84 42 64
86 56 64
104 78 64
143 118 64
144 119 64
169 148 64
185 160 64
50 48 64
55 53 64
121 95 64
187 161 64
228 202 64
247 221 64
267 342 64
287 703 64
407 883 64
507 983 64
527 1043 64
568 1084 64
667 1164 64
748 1284 64
787 1323 64
867 1403 64
907 1483 64
909 1485 64
547 1063 64
587 1106 64
687 1205 64
767 1303 64
807 1343 64

77 rows selected.

MOVO_NEW at omovo> create table COMPASSTEMPLET_bak as select * from COMPASSTEMPLET as of timestamp to_timestamp('2009-03-16 20:00:00','yyyy-mm-dd hh24:mi:ss');

Table created.


MOVO_NEW at omovo> update COMPASSTEMPLET c set c.templetbaseid = (select templetbaseid from COMPASSTEMPLET_bak where compassid=c.compassid);

77 rows updated.

确认查询是否有问题

MOVO_NEW at omovo> select * from COMPASSTEMPLET;

COMPASSTEMPLETID COMPASSID TEMPLETBASEID REMARK1 REMARK2
---------------- ---------- ------------- -------------------------------------------------- --------------------------------------------------
207 181 43
229 203 43
427 903 4
447 924 4
467 943 4
627 1124 4
887 1423 4
927 1503 4
307 763 63
308 764 64
327 803 4
347 823 83
367 843 103
390 867 64
607 1109 4
647 1143 4
707 1243 4
747 1283 4
828 1364 4
388 865 83
389 866 103
391 868 63
392 869 41
408 886 64
487 963 4
567 1083 4
727 1263 4
808 1344 4
827 1363 4
847 1383 4
47 45 6
48 46 5
102 76 4
103 77 4
49 47 7
3 3 1
53 51 4
85 55 4
141 115 4
146 124 4
1 1 8
2 2 2
38 38 3
101 75 4
12 43 3
45 44 3
54 52 4
84 42 11
86 56 9
104 78 11
143 118 10
144 119 9
169 148 21
185 160 41
50 48 4
55 53 2
121 95 12
187 161 4
228 202 4
247 221 4
267 342 4
287 703 4
407 883 4
507 983 4
527 1043 4
568 1084 4
667 1164 4
748 1284 4
787 1323 4
867 1403 4
907 1483 4
909 1485 4
547 1063 4
587 1106 4
687 1205 4
767 1303 4
807 1343 4

77 rows selected.

确定没问题，提交

MOVO_NEW at omovo> commit;

Commit complete.



疑问：
都这么长时间了，怎么还有问题啊

MOVO_NEW at omovo> show parameter undo

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_management string AUTO
undo_retention integer 900
undo_tablespace string UNDOTBS03

undo_retention ：指定只保留900秒啊！！

google一下，

UNDO_RETENTION参数用以控制事务提交以后UNDO信息保留的时间，UNDO信息可以减少ORA-01555错误及
一系列的闪回查询操作。该参数以秒为单位，在Oracle 9iR1中初始值为900秒，在Oracle 9iR2增加为
10800秒。但是这是一个非担保性(NO Guaranteed)限制，也就是说，如果有其他事务需要回滚空间，
而空间出现不足时，这些信息仍然会被覆盖，很多时候这是不希望被看到的。

从Oracle 10g开始，如果设置UNDO_RETENTION为0，那么Oracle启用自动调整以满足最长运行查询的需
要。当然如果表空间不足，那么Oracle最大允许的长时间查询，而不在需要用户手工调整。同时Oracl
e增加了Guarantee控制，也就是说，你可以指定UNDO表空间必须满足UNDO_RETENTION的限制，即使UNDO
空间不足，Oracle也不会回收未过期的UNDO空间，这样如果有用户请求UNDO空间得不到满足，则会报错
退出。Oracle 通过这项机制使得用户的期望可以被确保。


可以通过如下命令修改UNDO表空间的保证机制

alter tablespace undotbs1 retention guarantee;

alter tablespace undotbs1 retention noguarantee;

这个属性有3个选项：GUARANTEE、NOGUARANTEE和NOT APPLY.对于其他表空间这个属性不适用，显示为NOT APPLY。



经过分析，数据库在这段时间里应该很少有事物需要undo空间，所以一直没有被覆盖！！！，只是个人的见解









----end ----