转 rman 恢复报错

###sample 1 原因是新库起了FRA 区，FRA 区的旧文件属于之前的归档日志文件产生，这样会导致无法识别的问题。

解决办法，清空FRA或者恢复时候不启用FRA.

RMAN RESTORE FAILS WITH RMAN-06023 ALTHOUGH BACKUPS ARE AVAILABLE

After succesfully restoring controlfile from backup or starting database with a backup controlfile RMAN RESTORE DATABASE command fails with:

RMAN-00571: ====================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ========
RMAN-00571: ====================================================
RMAN-03002: failure of restore command at 11/11/2009 15:09:3
RMAN-06026: some targets not found - aborting restore
....
RMAN-06023: no backup or copy of datafile 3 found to restore
RMAN-06023: no backup or copy of datafile 2 found to restore
RMAN-06023: no backup or copy of datafile 1 found to restore

In the RMAN catalog we can see that there are available database backups.

CHANGES

none

CAUSE

The problem here is that there are some files in the Flash Recovery Area that belong to different incarnation than the available backups CURRENT incarnation.

If we start a RESTORE database with a BACKUP controlfile and Flash Recovery Area is defined, RMAN execute and implicit crosscheck and catalog of all the objects in the Flash Recovery Area.

We can see in the rman script messages like:

Starting restore at 11-11-2009 15:09:27
Starting implicit crosscheck backup at 11-11-2009 15:09:27
Finished implicit crosscheck backup at 11-11-2009 15:09:30

Starting implicit crosscheck copy at 11-11-2009 15:09:30
Finished implicit crosscheck copy at 11-11-2009 15:09:30

searching for all files in the recovery area
cataloging files...
cataloging done

List of Cataloged Files
=======================
File 1
File 2
... Etc

RMAN will catalog any objects in the Flash Recovery Area that will not be registered in the controlfile and if any of this files belongs to an incarnation different from CURRENT incarnation in the controlfile then changes controlfile CURRENT incarnation to the one found in the file tha is being cataloged.

This prevents database from restoring backups that belong to old CURRENT incarnation.
RMAN considers backup availble for being restored if the backup incarnation and CURRENT incarnation in controlfile are the same.

We can check that there are not backups belonging to CURRENT incarnation with command:

RMAN> LIST BACKUP RECOVERABLE;

This command only will show CURRENT incarnation available backups

SOLUTION

There are two options to fix the issue:

If the offending cataloged files are few then we can move those files to a directory outside the Flash Recovery Area then we need to restart the whole restore procedure. It's necessary to restore controlfile again
Another solution is to temporarily disable use of the flash recovery area for the duration of the restore and recovery commands.

To disable Flash Recovery Area you need to undefine db_recovery_file_dest:
2.1. Generate an init.ora file:

SQL> create pfile from spfile;

2.2 Edit the init.ora and comment the db_recovery_file_dest entries

#*.db_recovery_file_dest='<directory>'
#*.db_recovery_file_dest_size=<size>

2.3 Bounce database

SQL> shutdown;
SQL> startup nomount pfile='.... init.ora'

2.4 Restart the restore controlfile and then restore/recover database commands.

If there are some backuppieces or archivelogs in the Flash Recovery Area that need to be cataloged, then it will be necessary to catalog them manually with: CATALOG BACKUPPIECE or CATALOG ARCHIVELOG commands

### sample 2 RMAN-6026 RMAN-6023 when restoring to new host

原因为RMAN 没有重新CATALOG 新的备份片，导致备份片无法被控制文件识别，因此报错.,

解决办法，重新catalog.

RMAN restore to new host fails with:

RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 4 found to restore
RMAN-06023: no backup or copy of datafile 3 found to restore
RMAN-06023: no backup or copy of datafile 2 found to restore
RMAN-06023: no backup or copy of datafile 1 found to restore

CHANGES

Backups are made to disk and restored in another/different location at the new host.

CAUSE

RMAN will perform an implicit crosscheck which will mark the backups as EXPIRED.
RMAN looks for backups in the location where they were placed during the backup. The backups have been placed in a new directory on the new host.

To verify status of backups:

RMAN> crosscheck backup;
RMAN> crosscheck copy;

SOLUTION

Issuing the RMAN crosscheck command will verify if the backup exists on disk in the location
where it was placed during the backup.

The EXPIRED status occurred as customer had placed the backups in a different location.
The AVAILABLE status indicates that RMAN knows of the backup and will use the backup during the restore.

In order to tell RMAN that the location of the backups on disk has changed, use the RMAN catalog command.

example,

Cataloging Multiple Backups in a Directory:
The following example catalogs a directory of backup pieces that were copied into the /tmp directory with an operating system utility:

RMAN> CATALOG START WITH '/tmp/';

### sample 3

原因是恢复的数据库指定时间过于久远，可能是上一次resetlogs 之前的时间，所以无法识别那个时间段的信息。

解决办法：

RMAN> reset database to incarnation 1;

####
RMAN RESTORE fails with RMAN-06023 or ORA-19505 or RMAN-06100 inspite of proper backups (文档 ID 457769.1)

The debug trace reveals that the backupset 3 belongs to an ORPHAN branch of previous incarnation. Please refer the documentation for more information on Orphan backups and incarnations:

SOLUTION

Restore a control file from the previous incarnation in which the changes represented in the orphan backup has not been abandoned

or
Reset the database incarnation in current controlfile to the previous one and perform the restore:

RMAN RESTORE fails with RMAN-06023 or ORA-19505 or RMAN-06100 inspite of proper backups

We need to restore database/datafile using the following backup (BackupSet Key# 3):

RMAN> list backup of database;

using target database control file instead of recovery catalog

List of Backup Sets
===================

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ --------------------
3       Full    347.09M    DISK        00:00:41     07-SEP-2007 19:38:55
        BP Key: 3   Status: AVAILABLE  Compressed: NO  Tag: TAG20070907T193814
        Piece Name: D:\ORACLE\ORADATA\BACKUP\03IRC6P6_1_1
  List of Datafiles in backup set 3
  File LV Type Ckp SCN    Ckp Time             Name
  ---- -- ---- ---------- -------------------- ----
  1       Full 360352     07-SEP-2007 19:38:14 D:\ORACLE\ORADATA\ORA10G\SYSTEM01.DBF
  2       Full 360352     07-SEP-2007 19:38:14 D:\ORACLE\ORADATA\ORA10G\UNDOTBS01.DBF
  3       Full 360352     07-SEP-2007 19:38:14 D:\ORACLE\ORADATA\ORA10G\SYSAUX01.DBF

+ However the restore fails with following error:

RMAN> restore datafile 1;

Starting restore at 07-SEP-2007 20:38:21
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=46 devtype=DISK

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 09/07/2007 20:38:22
RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 1 found to restore

OR, with following errors when looking for other backups:
(In case other previous backups exist for this database but we are interested in restoring from the latest backup with BackupSet Key# 3)

ORA-19870: error reading backup piece D:\ORACLE\ORADATA\BACKUP\01IRC6C4_1_1
ORA-19505: failed to identify file "D:\ORACLE\ORADATA\BACKUP\01IRC6C4_1_1"
ORA-27041: unable to open file
OSD-04002: unable to open file
OR
RMAN-06026: some targets not found - aborting restore
RMAN-06100: no channel to restore a backup or copy of datafile 1

Or, with below errors after no backup is found and RMAN tries to create the datafile:

creating datafile fno=1 name=+DATA/pzrsa/datafile/system.288.585590761
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 03/21/2006 21:41:34
ORA-01180: can not create datafile 1
ORA-01110: data file 1: '+DATA/pzrsa/datafile/system.288.585590761'

+ We have verified that the backupset 3 is available and accessible:

RMAN> crosscheck backupset 3;

using channel ORA_DISK_1
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=D:\ORACLE\ORADATA\BACKUP\03IRC6P6_1_1 recid=3 stamp=632691494
Crosschecked 1 objects

+ Also the backup exists on DISK and the allocated default channel is of type DISK so there is no mismatch of allocated and required channel type.

+ The checkpoint SCN of datafile 1 in backupset 3 i.e. 360352, seems to belong to the current incarnation (Reset SCN=360002) so there is no mismatch in the incarnation as well:

RMAN> list incarnation of database;

List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1       1       ORA10G   3944965565       PARENT  289857     19-AUG-2007 22:31:27
2       2       ORA10G   3944965565       CURRENT 360002     07-SEP-2007 19:44:56

CAUSE

Debug the restore session using:

C:\>rman target / log=rmanLog.txt trace=rmanTrace.txt
RMAN> debug on;
RMAN> restore datafile 1;
RMAN> debug off;
RMAN> exit;

rmanLog.txt
===========
RMAN-03090: Starting restore at 07-SEP-2007 21:07:14
RMAN-06009: using target database control file instead of recovery catalog
RMAN-08030: allocated channel: ORA_DISK_1
RMAN-08500: channel ORA_DISK_1: sid=49 devtype=DISK

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 09/07/2007 21:08:34
RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 1 found to restore

rmanTrace.txt
=============
(Search the debug trace for Checkpoint SCN: "360352" of datafile #1 in backupset #3)
...
DBGRCVMAN:  CheckRecAction called 08/19/07 22:31:27; rlgscn=289857
DBGRCVMAN: CheckRecAction: inc=1,toscn=360352exceeds 360002
DBGRCVMAN: CheckRecAction:belongs to orphan branch of this incarnation:
...

The debug trace reveals that the backupset 3 belongs to an ORPHAN branch of previous incarnation. Please refer the documentation for more information on Orphan backups and incarnations:

Oracle Database Backup and Recovery Basics 10g Release 2 (10.2)

7.6.2.3 Database Incarnations and Orphaned Backups

This problem usually occurs when restoring on a new instance with FRA configured. When restoring database using a backup controlfile, RMAN automatically catalogs all archives inside the FRA. If there are left over archives, they can add incarnation branches to the restored controlfile causing this issue.

If this is the case, you may consider cleaning up the FRA before starting restore/recover process.

SOLUTION

Restore a control file from the previous incarnation in which the changes represented in the orphan backup has not been abandoned

OR

Reset the database incarnation in current controlfile to the previous one and perform the restore:

RMAN> list incarnation of database;

List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1       1       ORA10G   3944965565       PARENT  289857     19-AUG-2007 22:31:27
2       2       ORA10G   3944965565       CURRENT 360002     07-SEP-2007 19:44:56

RMAN> reset database to incarnation 1;

database reset to incarnation 1

RMAN> restore datafile 1;

Starting restore at 07-SEP-2007 21:23:55
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=46 devtype=DISK

channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to D:\ORACLE\ORADATA\ORA10G\SYSTEM01.DBF
channel ORA_DISK_1: reading from backup piece D:\ORACLE\ORADATA\BACKUP\03IRC6P6_1_1
channel ORA_DISK_1: restored backup piece 1
piece handle=D:\ORACLE\ORADATA\BACKUP\03IRC6P6_1_1 tag=TAG20070907T193814
channel ORA_DISK_1: restore complete, elapsed time: 00:00:36
Finished restore at 07-SEP-2007 21:24:32

###############sample 4

原因是恢复时间过于久远，本地备份片都是无法识别，所以需要检查脚本里是或否有问题。

检查恢复脚本，确认恢复的序列号是最近的序列号

SQL> select max(sequence#) from v$archived_log L, v$database D

where L.resetlogs_change# = D.resetlogs_change# and

thread#=1;

       MAX(SEQUENCE#)
       --------------
               25

    SQL> select max(sequence#) from v$archived_log L, v$database D

where L.resetlogs_change# = D.resetlogs_change# and

thread#=2;

SQL> select sequence#, thread#, first_change#, next_change#
             from v$archived_log L, v$database D
   where L.resetlogs_change# = D.resetlogs_change# and
             sequence# in (13,25);

      SEQUENCE#    THREAD# FIRST_CHANGE# NEXT_CHANGE#
     -------------------- -------------- ------------------------- -------------------------
            25            1        1744432    1744802
            13          2       1744429        1744805

CHANGES

CAUSE

SOLUTION

CHANGES

CAUSE

SOLUTION

CAUSE

SOLUTION

猜你喜欢