ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 基于冷备份的完全恢复

基于冷备份的完全恢复

原创 Linux操作系统 作者:尛样儿 时间:2012-07-19 22:37:46 0 删除 编辑
        下面讨论演练这样一个场景,时间点T1在关闭数据库的情况下执行了数据库的全库冷备份(控制文件、数据文件和在线Redo日志文件)。之后继续启动数据库运行,在时间T2,数据库异常宕机,且所有的控制文件、数据文件丢失,冷备份、归档Redo日志和在线Redo日志还存在,下面讨论执行完全恢复的过程。

SQL> alter system switch logfile;

系统已更改。

SQL> archive log list;
数据库日志模式            存档模式
自动存档             启用
存档终点            USE_DB_RECOVERY_FILE_DEST
最早的联机日志序列     1
下一个存档日志序列   3
当前日志序列           3
SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。

--执行数据库冷备份,用winrar对orcl目录创建rar包。

SQL> startup
ORACLE 例程已经启动。

Total System Global Area  313860096 bytes
Fixed Size                  1384352 bytes
Variable Size             155189344 bytes
Database Buffers          150994944 bytes
Redo Buffers                6291456 bytes
数据库装载完毕。
数据库已经打开。
SQL> alter system switch logfile;

系统已更改。

SQL> r
  1* alter system switch logfile

系统已更改。

SQL> r
  1* alter system switch logfile

系统已更改。

--创建一张test111测试表。

SQL> create table test111(id number);

表已创建。

SQL> insert into test111 values(1);

已创建 1 行。

SQL> commit;

提交完成。

SQL> alter system switch logfile;

系统已更改。

--模拟系统异常宕机。
SQL> shutdown abort
ORACLE 例程已经关闭。
SQL> exit
从 Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options 断开

--将orcl目录重命名成orcl111目录。
--将orcl.rar包解压。
--启动数据库到MOUNT状态。
C:\Users\LIUBINGLIN>sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on 星期四 7月 19 22:31:57 2012

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

已连接到空闲例程。

SQL> startup mount
ORACLE 例程已经启动。

Total System Global Area  313860096 bytes
Fixed Size                  1384352 bytes
Variable Size             155189344 bytes
Database Buffers          150994944 bytes
Redo Buffers                6291456 bytes
数据库装载完毕。

--这个时候的数据库状态是冷备份时候的状态,是一执行的状态,但要求将数据库恢复到最新的时间点,那么冷备份中包含的在线Redo日志是旧的数据,没有任何意义。下面需要应用冷备份之后的归档Redo日志和在线Redo日志。
SQL> recover database;
ORA-00283: recovery session canceled due to errors
ORA-00264: no recovery required
执行recover database是显然行不通的。

SQL> recover database using backup controlfile;
ORA-00279: 更改 1191201 (在 07/19/2012 22:20:54 生成) 对于线程 1 是必需的
ORA-00289: 建议:
E:\APP\FAST_RECOVERY_AREA\ORCL\ARCHIVELOG\2012_07_19\O1_MF_1_3_80J67B9J_.ARC
ORA-00280: 更改 1191201 (用于线程 1) 在序列 #3 中


指定日志: {=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: 更改 1191472 (在 07/19/2012 22:25:45 生成) 对于线程 1 是必需的
ORA-00289: 建议:
E:\APP\FAST_RECOVERY_AREA\ORCL\ARCHIVELOG\2012_07_19\O1_MF_1_4_80J67C0J_.ARC
ORA-00280: 更改 1191472 (用于线程 1) 在序列 #4 中
ORA-00278: 此恢复不再需要日志文件
'E:\APP\FAST_RECOVERY_AREA\ORCL\ARCHIVELOG\2012_07_19\O1_MF_1_3_80J67B9J_.ARC'


ORA-00279: 更改 1191475 (在 07/19/2012 22:25:46 生成) 对于线程 1 是必需的
ORA-00289: 建议:
E:\APP\FAST_RECOVERY_AREA\ORCL\ARCHIVELOG\2012_07_19\O1_MF_1_5_80J67GY9_.ARC
ORA-00280: 更改 1191475 (用于线程 1) 在序列 #5 中
ORA-00278: 此恢复不再需要日志文件
'E:\APP\FAST_RECOVERY_AREA\ORCL\ARCHIVELOG\2012_07_19\O1_MF_1_4_80J67C0J_.ARC'


ORA-00279: 更改 1191479 (在 07/19/2012 22:25:50 生成) 对于线程 1 是必需的
ORA-00289: 建议:
E:\APP\FAST_RECOVERY_AREA\ORCL\ARCHIVELOG\2012_07_19\O1_MF_1_6_80J689DD_.ARC
ORA-00280: 更改 1191479 (用于线程 1) 在序列 #6 中
ORA-00278: 此恢复不再需要日志文件
'E:\APP\FAST_RECOVERY_AREA\ORCL\ARCHIVELOG\2012_07_19\O1_MF_1_5_80J67GY9_.ARC'


ORA-00279: 更改 1191507 (在 07/19/2012 22:26:17 生成) 对于线程 1 是必需的
ORA-00289: 建议:
E:\APP\FAST_RECOVERY_AREA\ORCL\ARCHIVELOG\2012_07_19\O1_MF_1_7_%U_.ARC
ORA-00280: 更改 1191507 (用于线程 1) 在序列 #7 中
ORA-00278: 此恢复不再需要日志文件
'E:\APP\FAST_RECOVERY_AREA\ORCL\ARCHIVELOG\2012_07_19\O1_MF_1_6_80J689DD_.ARC'


ORA-00308: cannot open archived log
'E:\APP\FAST_RECOVERY_AREA\ORCL\ARCHIVELOG\2012_07_19\O1_MF_1_7_%U_.ARC'
ORA-27041: unable to open file
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。
--在所有的归档Redo日志都存在,且目录没有发生变化的情况下,报无法打开文件通常是因为无法找到最新的在线Redo日志。只需要重新执行恢复命令,手动指定当前的在线Redo日志即可。

SQL> recover database using backup controlfile;
ORA-00279: 更改 1191507 (在 07/19/2012 22:26:17 生成) 对于线程 1 是必需的
ORA-00289: 建议:
E:\APP\FAST_RECOVERY_AREA\ORCL\ARCHIVELOG\2012_07_19\O1_MF_1_7_%U_.ARC
ORA-00280: 更改 1191507 (用于线程 1) 在序列 #7 中


指定日志: {=suggested | filename | AUTO | CANCEL}
E:\app\oradata\orcl111\REDO01.LOG
已应用的日志。
完成介质恢复。
SQL> alter database open resetlogs;

数据库已更改。

SQL> select * from test111;

        ID
----------
         1

       如果当前的在线Redo日志丢失,那么数据库无法执行完全恢复,如果运气好的话,执行alter database open resetlogs能够顺利打开数据库;如果运气不好,就会收到需要介质恢复的报错(通常是file# 1),这时只有强制打开数据库。另外,即使应用了当前的在线Redo日志,由于使用backup controlfile恢复,Oracle也认为是不完全恢复,需要open resetlogs,但它实际是完全恢复。ITPUB论坛中出现过一篇非常有意义的有关open resetlogs的讨论,可以参考学习:http://www.itpub.net/thread-1630086-1-1.html

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/23135684/viewspace-736088/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
Oracle数据库管理员,Oracle数据库系统构架员;2012年7月出版《构建最高可用Oracle数据库系统:Oracle 11gR2 RAC管理、维护与性能优化》一书;Oracle 10g OCM。

注册时间:2010-01-05

  • 博文量
    483
  • 访问量
    5258965