recover database using backup controlfile until cancel 假recover，真一致

复制代码

Solution Explanation: =====================  Even though media recovery is cancelled without applying archive logs, the database is consistent and is able to come up.

复制代码

Basically the datafiles needed only the redo logs to be consistent and we attempted a fake recovery to bring up the database.

Summary

复制代码

NOTE: In the images and/or the document content below, the user information and environment data used represents fictitious data from theOracle sample schema(s), Public Documentation delivered with an Oracle database product or other training material. Any similarity to actualenvironments, actual persons, living or dead, is purely coincidental and not intended in any manner.

For the purposes of this document, the following fictitious environment is used as an example to describe the procedure:

Database Name: RMAN1
Directory Name: /home/rman1/ and all sub-directories

复制代码

While performing recovery using RMAN, you receive the following error after doing a 'restore database':

RMAN-08060: unable to find archivelog
RMAN-08510: archivelog thread=1 sequence=73

复制代码

Following is a sample of the RMAN log :

RMAN-03022: compiling command: recover(3)
RMAN-03023: executing command: recover(3)
RMAN-08054: starting media recovery
RMAN-08060: unable to find archivelog
RMAN-08510: archivelog thread=1 sequence=73
RMAN-03022: compiling command: recover(4)
RMAN-03026: error recovery releasing channel resources
RMAN-08031: released channel: c1
RMAN-00569: ================error message stack follows================
RMAN-03002: failure during compilation of command
RMAN-03013: command type: recover
RMAN-03002: failure during compilation of command
RMAN-03013: command type: recover(4)
RMAN-06038: recovery catalog package detected an error
RMAN-20242: specification does not match any archivelog in the recovery catalog

复制代码

Solution

复制代码

Use commands in svrmgrl to recover the database and open the database.The RMAN script to restore and recover database is as follows:

RMAN> run {
allocate channel c1 type disk;
restore controlfile;
restore database;
sql 'alter database mount';
recover database;
sql 'alter database open resetlogs';
}

复制代码

The following errors:

RMAN-08060: unable to find archivelog
RMAN-08510: archivelog thread=1 sequence=73

复制代码

come up after the database is mounted and recovery ('recover database' in the  script) is in progress.Open a svrmgrl session and try the following command :

alter database open resetlogs;

复制代码

to observe, for eg :

ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/home/rman1/system01.dbf'

复制代码

Execute the following command :

SVRMGR> recover database;
ORA-00283: recovery session canceled due to errors
ORA-01610: recovery using the BACKUP CONTROLFILE option must be done
SVRMGR> recover database using backup controlfile until cancel
ORA-00279: change 14049 generated at 09/18/99 20:10:12 needed for thread 1
ORA-00289: suggestion : /home/rman1/arch/1_73.dbf
ORA-00280: change 14049 for thread 1 is in sequence #73
Specify log: {<RET>=suggested | filename | AUTO | CANCEL} CANCEL Media recovery cancelled.
SVRMGR> alter database open resetlogs;
Statement processed.

复制代码

In the RMAN session : =====================

RMAN> reset database;

RMAN-03022: compiling command: reset
RMAN-03023: executing command: reset
RMAN-08006: database registered in recovery catalog
RMAN-03023: executing command: full resync
RMAN-08002: starting full resync of recovery catalog
RMAN-08004: full resync complete

RMAN> list incarnation of database;

RMAN-03022: compiling command: list
RMAN-06240: List of Database Incarnations
RMAN-06241: DB Key Inc Key DB Name DB ID CUR Reset SCN Reset Time
RMAN-06242: ------------------------------------------------------
RMAN-06243: 1 2 RMAN1 64857501 NO 1 12-SEP-99
RMAN-06243: 1 216 RMAN1 64857501 YES 14050 19-SEP-99

复制代码

Note: the new 'Inc Key' value since the database was opened with RESETLOGS option.

复制代码

Solution Explanation: =====================  Even though media recovery is cancelled without applying archive logs, the database is consistent and is able to come up.

复制代码

Basically the datafiles needed only the redo logs to be consistent and we attempted a fake recovery to bring up the database.

NOTE : DO NOT try to 'reset database to incarnation 2' , you may have to go through all the steps once again only to notice the following :
RMAN> list incarnation of database;