基于时间的不完全恢复

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介:        基于时间的不完全恢复是指当出现了用户错误比如失误操作 drop table ,truncate table 时,使用备份文件,归档日志和重做日志文件将数据库恢复到用户误操作点的状态,从而恢复用户数据。

       基于时间的不完全恢复是指当出现了用户错误比如失误操作 drop table ,truncate table 时,使用备份文件,归档日志和重做日志文件将数据库恢复到用户误操作点的状态,从而恢复用户数据。

实验步骤如下:

1)先建立一个test表,并插入数据1, 2, 3,提交,切换日志文件。

SQL> create table t1 (num number) tablespace test;

表已创建。

SQL> insert into t1 values (1);

已创建 1 行。

SQL> commit;

提交完成。

SQL> insert into t1 values (2);

已创建 1 行。

SQL> commit;

提交完成。

SQL> alter system switch logfile;

系统已更改。

SQL> insert into t1 values (3);

已创建 1 行。

SQL> commit;

提交完成。

SQL> alter system switch logfile;

系统已更改。

2)查看误操作的时间点. 删除表。

SQL> host date

2010-05-12

SQL> host time

21:16:56'

SQL> drop table t1;

表已删除。

3)关闭数据库,在使数据库处于加载状态

SQL> shut immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup mount
ORACLE 例程已经启动。

Total System Global Area  535662592 bytes                                      
Fixed Size                  1334380 bytes                                      
Variable Size             138412948 bytes                                      
Database Buffers          390070272 bytes                                      
Redo Buffers                5844992 bytes                                      
数据库装载完毕。

4)复制所有数据文件备份,为了将数据库恢复到过去的时间点,必须复制所以数据文件的备份。

SQL> @f:\sql\recover.sql

注意:当复制备份文件时,必须确保备份文件的时间点在恢复时间点之前。可以通过以下查询获取备份文件的时间点:

SQL> select file#,to_char(time,'yyyy-mm-dd hh24:mi:ss') from v$recover_file;

     FILE# TO_CHAR(TIME,'YYYY-                                                 
---------- -------------------                                                 
       1 2010-05-10 16:24:02                                                 
         2 2010-05-10 16:24:02                                                 
         3 2010-05-10 16:24:02                                                 
         4 2010-05-10 16:24:02
         5 2010-05-10 16:24:02   
         6 2010-05-10 16:24:02

 2010-05-10 16:24:02  小于 '2010-05-12 21:16:56'
SQL> recover database until time '2010-05-12 21:16:56'
ORA-00279: 更改 2442330 (在 05/11/2010 22:40:23 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\79_1_715961434.LOG
ORA-00280: 更改 2442330 (用于线程 1) 在序列 #79 中
指定日志: {=suggested | filename | AUTO | CANCEL}
auto
已应用的日志。
完成介质恢复。

5)以resetlogs方式打开数据库。
SQL> alter database open resetlogs;

数据库已更改。

SQL> select * from t1;

       NUM                                                                     
----------                                                                     
         1                                                                     
         2                                                                     
         3
        ------------由查询结果可知 恢复成功。         

6)当然执行了resetlogs之后,建议进行数据库的全备份。
SQL> archive log list
数据库日志模式            存档模式
自动存档             启用
存档终点            f:\app\yang\archive2
最早的联机日志序列     1
下一个存档日志序列   1
当前日志序列           1


SQL> alter database begin backup;

数据库已更改。

SQL> @f:\sql\hotbak.sql----关于备份的脚本
SQL> alter database end backup;

数据库已更改。

SQL> alter database backup controlfile
  2  to 'f:\lib\control.ctl' reuse;

数据库已更改。

SQL> alter system archive log current;------保持一致性。这一步,有时容易忽略

系统已更改

                                                    

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
数据库
数据库恢复技术
数据库恢复技术
125 0
|
安全 数据库
事务故障恢复
事务故障恢复
270 0
事务故障恢复
|
数据库
即使删了全库,保证半小时恢复
近期一篇《就这样把根目录删了!!!》引发了广泛的讨论,《如何防止根目录被删》汇总了7种防删方案。还有同学评论中反馈“不小心把库删了”,如何快速恢复删掉的数据库,是今天要讨论的话题。
821 0