基于冷备份的完全恢复

        下面讨论演练这样一个场景，时间点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/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/23135684/viewspace-736088/