基于取消的不完全恢复

简介: 基于取消的不完全恢复是指数据库恢复到特定日志序列号之前的状态。当因丢失归档日志或重做日志完全恢复失败时,可以使用这种方法。 在做这个实验时我是将序列号位 23的日志文件删除了。

基于取消的不完全恢复是指数据库恢复到特定日志序列号之前的状态。当因丢失归档日志或重做日志完全恢复失败时,可以使用这种方法。

在做这个实验时我是将序列号位 23的日志文件删除了。实验表t1;

SQL> select * from t1;

       NUM                                                                     
----------                                                                     
         1                                                                     
         2                                                                     
         3                                                                     
         4                                                                     
         5                                                                     
         6                                                                     

已选择6行。

模拟实验环境,删除t1表所在的数据文件 test.dbf

1)关闭数据库,将数据打开至加载状态。执行不完全恢复时数据库必须在mount状态。

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

Total System Global Area  535662592 bytes                                      
Fixed Size                  1334380 bytes                                      
Variable Size             142607252 bytes                                      
Database Buffers          385875968 bytes                                      
Redo Buffers                5844992 bytes                                      
数据库装载完毕。
ORA-01157: 无法标识/锁定数据文件 6 - 请参阅 DBWR 跟踪文件
ORA-01110: 数据文件 6: 'F:\APP\YANG\ORADATA\ORACL\TEST.DBF'
 

2)  复制所有数据文件备份。                                                               

SQL> @f:\sql\recover.sql
SQL> select file#,change# from v$recover_file;

     FILE#    CHANGE#                                                          
---------- ----------                                                          
         1    2558251                                                          
         2    2558251                                                          
         3    2558251                                                          
         4    2558251                                                          
         5    2558251                                                          
         6    2558251                                                          

已选择6行。

----当复制数据文件备份时,必须确保备份文件的scn值小于要恢复到的scn值。

2558251     !

SQL> select max(first_change#) fchange from v$log_history where sequence#=23;

   FCHANGE                                                                     
----------                                                                     
   2559954            

3)执行  recover database until cancel 命令。                                                       

SQL> recover database until cancel;
ORA-00279: 更改 2558251 (在 05/14/2010 12:33:26 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\13_1_718839060.LOG
ORA-00280: 更改 2558251 (用于线程 1) 在序列 #13 中

指定日志: {=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: 警告: RECOVER 成功但 OPEN RESETLOGS 将出现如下错误
ORA-01195: 文件 1 的联机备份需要更多的恢复来保持一致性
ORA-01110: 数据文件 1: 'F:\APP\YANG\ORADATA\ORACL\SYSTEM01.DBF'


ORA-01112: 未启动介质恢复

SQL> recover database until cancel;
ORA-00279: 更改 2558251 (在 05/14/2010 12:33:26 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\13_1_718839060.LOG
ORA-00280: 更改 2558251 (用于线程 1) 在序列 #13 中

指定日志: {=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: 更改 2558455 (在 05/14/2010 12:38:45 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\14_1_718839060.LOG
ORA-00280: 更改 2558455 (用于线程 1) 在序列 #14 中
ORA-00278: 此恢复不再需要日志文件 'F:\APP\YANG\ARCHIVE2\13_1_718839060.LOG'

ORA-00279: 更改 2558787 (在 05/14/2010 12:45:57 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\15_1_718839060.LOG
ORA-00280: 更改 2558787 (用于线程 1) 在序列 #15 中
ORA-00278: 此恢复不再需要日志文件 'F:\APP\YANG\ARCHIVE2\14_1_718839060.LOG'

ORA-00279: 更改 2558793 (在 05/14/2010 12:46:07 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\16_1_718839060.LOG
ORA-00280: 更改 2558793 (用于线程 1) 在序列 #16 中
ORA-00278: 此恢复不再需要日志文件 'F:\APP\YANG\ARCHIVE2\15_1_718839060.LOG'

ORA-00279: 更改 2558799 (在 05/14/2010 12:46:18 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\17_1_718839060.LOG
ORA-00280: 更改 2558799 (用于线程 1) 在序列 #17 中
ORA-00278: 此恢复不再需要日志文件 'F:\APP\YANG\ARCHIVE2\16_1_718839060.LOG'

ORA-00279: 更改 2558818 (在 05/14/2010 12:46:33 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\18_1_718839060.LOG
ORA-00280: 更改 2558818 (用于线程 1) 在序列 #18 中
ORA-00278: 此恢复不再需要日志文件 'F:\APP\YANG\ARCHIVE2\17_1_718839060.LOG'

ORA-00279: 更改 2559925 (在 05/14/2010 13:14:21 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\19_1_718839060.LOG
ORA-00280: 更改 2559925 (用于线程 1) 在序列 #19 中
ORA-00278: 此恢复不再需要日志文件 'F:\APP\YANG\ARCHIVE2\18_1_718839060.LOG'

ORA-00279: 更改 2559934 (在 05/14/2010 13:14:41 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\20_1_718839060.LOG
ORA-00280: 更改 2559934 (用于线程 1) 在序列 #20 中
ORA-00278: 此恢复不再需要日志文件 'F:\APP\YANG\ARCHIVE2\19_1_718839060.LOG'

ORA-00279: 更改 2559942 (在 05/14/2010 13:14:57 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\21_1_718839060.LOG
ORA-00280: 更改 2559942 (用于线程 1) 在序列 #21 中
ORA-00278: 此恢复不再需要日志文件 'F:\APP\YANG\ARCHIVE2\20_1_718839060.LOG'

ORA-00279: 更改 2559948 (在 05/14/2010 13:15:06 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\22_1_718839060.LOG
ORA-00280: 更改 2559948 (用于线程 1) 在序列 #22 中
ORA-00278: 此恢复不再需要日志文件 'F:\APP\YANG\ARCHIVE2\21_1_718839060.LOG'

ORA-00308: 无法打开归档日志 'F:\APP\YANG\ARCHIVE2\22_1_718839060.LOG'
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。

SQL> recover database until cancel;
ORA-00279: 更改 2559948 (在 05/14/2010 13:15:06 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\22_1_718839060.LOG
ORA-00280: 更改 2559948 (用于线程 1) 在序列 #22 中

4)alter database open resetlogs,查看恢复是否成功。。
SQL> alter database open resetlogs;
数据库已更改

SQL> select * from t1;

       NUM                                                                     
----------                                                                     
         1                                                                     
         2                                                                     
         3                                                                     
         4
         

数据库的不完全恢复 成功。。。。。

5)执行了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;
系统已更改。

结束语: 做这个实验做了好几次都没成功,当执行第三步时,先输入cancel 提示,取消介质恢复。输入auto后,数据库才利用归档日志进行恢复。关于这一点,我有点不清楚了,既然是基于cancel的,为什么还要输入auto呢?请哪位看官给个解答。谢谢了
                         

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
安全 数据库
事务故障恢复
事务故障恢复
234 0
事务故障恢复
|
消息中间件 存储 RocketMQ
正常恢复和异常恢复|学习笔记
快速学习正常恢复和异常恢复
94 0
|
数据库 SQL 关系型数据库
|
SQL 关系型数据库 MySQL
mysql备份单个表恢复失败
问题 备份数据库 mysqldump -uroot -p database_name tab1 > test.sql; # 远程加 -h 恢复数据库 使用的是source,进入数据库以后 use database_name; source test.