phantominORACLE 2015-11-27
【说明】无意中看到一个同事的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分钟的话要看天吃饭了。
以下是闪回查询的原理。
Oracle数据库的undo表空间用于存放数据删除前的前镜像,保证了数据的读一致性。所以数据被更新或删除的时候,数据并没有马上消失,而是会放在undo表空间里面的。
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表空间的使用情况,进行调整。