oracle数据库rman恢复数据库,使用RMAN恢复完全损坏的数据库

(转自 metalink.oracle.com)

The purpose of this article is to describe how to recover a database from a total failure using RMAN 8i.

This article is meant to assist you in performing an incomplete recovery after losing all datafiles, online redo logs, and control files.

You need Oracle Services for the database and an init.ora file. Additionally, if you have archive logs that have not been cataloged, you will be able to use them as part of the recovery.

1.RESTORE CONTROLFILE

set ORACLE_SID=PROD

svrmgr> connect internal

svrmgr> startup nomount pfile=

svrmgr> Exit

set ORACLE_SID=PROD

RMAN TARGET INTERNAL/password CATALOG  rman/rman@rcat

RMAN>  run {

allocate channel c1 type disk;

restore controlfile;

alter database mount;

release channel c1;

}

2.QUERY TARGET AND CATALOG DATABASE

Connect to the catalog database and issue the following:

set ORACLE_SID=RCAT

svrmgr> connect rman/rman

svrmgr>

select sequence#, thread#, low_scn, next_scn from rlh;

SEQUENCE#    THREAD#    LOW_SCN   NEXT_SCN

----------                 ----------     ----------         ----------

188                      1               37278

189                      1               37891

190                      1               38231

191                      1               38319

192                      1               38389

193                      1               38468

194                      1               38562

195                      1               38649

196                      1               38708

197                      1               38844

Note the last SCN is 197.  This is the last System Change Number that the RMAN catalog is aware of.

Now connect to the target database:

set ORACLE_SID=PROD

svrmgr> connect internal

svrmgr> select * from v$log_history

RECID      STAMP            THREAD#  SEQUENCE#   FIRST_CHANGE#    FIRST_TIM   NEXT_CHANGE#

----------         ----------          ----------      ---------- -               ------------             ---------     ------------

188           410011317          1                    188            & 37278

189           410011323          1                    189            & 37891

190           410011328          1                    190            & 38231

191           410011332          1                    191            & 38319

192           410011338          1                    192            & 38389

193           410011341          1                    193            & 38468

194           410011345          1                    194            & 38562

195           410011349          1                    195            & 38649

196           410011352          1                    196            & 38708

197           410011551          1                    197            & 38844

Since the database has been mounted using a backup control file, the last Log Sequence Number that the control file is aware of is 197. This happens to match the last LSN known by the catalog because a resync has not been performed since the last backup. But if you look in the archive dump destination, you may see additional archive logs that have not been cataloged. You need to catalog these files so that RMAN can use them during the recovery.

Directory of D:\ORACLE\oradata\PROD\archive

0/03/00  11:46a        

0/03/00  11:46a        

0/03/00  12:09p                 11,264  PRODT001S00198.ARC

0/03/00  12:09p                 11,264  PRODT001S00199.ARC

0/03/00  12:09p                 1,024    PRODT001S00200.ARC

0/03/00  12:09p                 1,024    PRODT001S00201.ARC

3. MANUALLY CATALOG ANY INTERMEDIATE ARCHIVED LOGS

Archive logs 198 through 201 are available but have not been recorded in the catalog.

Perform the following for each available archive log:

set ORACLE_SID=PROD

RMAN TARGET INTERNAL/password CATALOG  rman/rman@rcat

RMAN> catalog archivelog 'd:\oracle\oradata\prod\archive\PRODT001S00198.ARC';

4. RESTORE AND RECOVER DATABASE

The last archive log available has a log sequence number of 201, so you can perform an incomplete recovery using logs up to and including PRODT001S00201.ARC.

RMAN> run {

allocate channel c1 type disk;

set until logseq 201 thread 1;

restore database;

recover database;

release channel c1;

sql "alter database open resetlogs";

}

5. RESET THE DATABASE

Before you can use RMAN again with a target database that has been opened with the RESETLOGS option, you must notify RMAN that you have reset the database incarnation.  The reset database command directs RMAN to create a new database incarnation record in the recovery catalog.

RMAN> reset database;

RMAN> List Incarnation of database;

List of Database Incarnations

DB Key  Inc Key       DB Name      DB ID              CUR         Reset SCN          Reset Time

-------      -------         --------        ----------------     ----          ------------          ------------

1               2               PROD         4116816026       NO              1                     03-OCT-00

1               429           PROD         4116816026       YES            38872             03-OCT-00

6. BACKUP DATABASE

Immediately backup the database. Because the database is a new incarnation, the pre-RESETLOG backups are not usable. Prior to running the backup, remove the old archive log file from the archive dump destination.

RMAN> run {

shutdown immediate;

startup mount pfile=;

allocate channel c1 type disk format 'e:\oracle\oradata\backup\df_%d_%p_%c_%s';

backup database;

release channel c1;

allocate channel c1 type disk format 'e:\oracle\oradata\backup\archive\al_%d_%s_%c';

backup (archivelog all delete input);

sql 'alter database open';

release channel c1;

}