RMAN RESTORE fails with RMAN-00600 [8064]

Posted by PDSERVICE on Mar 08, 2020 In

APPLIES TO:

Oracle Database - Enterprise Edition - Version 10.2.0.1 to 10.2.0.4 [Release 10.2]

Oracle Database Cloud Schema Service - Version N/A and later

Oracle Database Exadata Express Cloud Service - Version N/A and later

Oracle Database Exadata Cloud Machine - Version N/A and later

Oracle Cloud Infrastructure - Database Service - Version N/A and later

Information in this document applies to any platform.

SYMPTOMS

When RMAN backup is restored to a new database with the same datafile paths as production server, the RESTORE fails with RMAN-00600 [8064]. The error stack looks like the following:

RMAN> restore database preview;

Starting restore at 03-JUN-09

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=415 devtype=DISK

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-00601: fatal error in recovery manager

RMAN-03012: fatal error during compilation of command

RMAN-03028: fatal error code for command restore : 600

RMAN-00600: internal error, arguments [8064] [1] [<path>\<db_unique_name of restored db>\SYSTEM01.DBF]

[<path>\<db_unique_name of prod>\SYSTEM01.DBF] []

CHANGES

The path of datafiles in controlfile of production server is different from the path stored in recovery catalog:

SQL> select name from v$datafile ;

NAME

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

<path>\<db_unique_name of prod>\SYSTEM01.DBF

<path>\<db_unique_name of prod>\UNDOTBS01.DBF

<path>\<db_unique_name of prod>\UNDOTBS02.DBF

.............

RMAN Connected WITHOUT recovery catalog

=================================

RMAN> report schema;

Report of database schema

List of Permanent Datafiles

===========================

File Size(MB) Tablespace RB segs Da0tafile Name

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

1 2048 SYSTEM *** <path>\<db_unique_name of prod>\SYSTEM01.DBF

2 2048 UNDO *** <path>\<db_unique_name of prod>\UNDOTBS01.DBF

................

RMAN Connected WITH recovery catalog

=========================

RMAN> report schema;

Report of database schema

List of Permanent Datafiles

===========================

File Size(MB) Tablespace RB segs Datafile Name

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

1 2048 SYSTEM YES <path>\<db_unique_name of previous clone activity>\SYSTEM01.DBF

2 2048 UNDO YES <path>\<db_unique_name of previous clone activity>\UNDOTBS01.DBF

................

RMAN> list incarnation;

List of Database Incarnations

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

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

1 1 <db_unique_name prod> <dbid> CURRENT 1 15/AUG/08

View RC_DATAFILE will also show a different path then controlfile (V$DATAFILE) of production database.

CAUSE

While cloning the database, when an RMAN RESTORE is attempted to a new location while connected to recovery catalog, the catlaog is resynced with the new path as a result of SWITCH DATAFILE ALL command.

If the DBID/DBNAME is not changed, the backup of production database (original database) will still be successfully completed even if the location in controlfile ( V$DATAFILE) and recovery catalog (RC_DATAFILE or REPORT SCHEMA) are different. This is because the RMAN reads File# instead of NAME for backup activities.

A next cloning attempt from RMAN connected with recovery catalog on a new server, this time with original path structures as present in production database controlfile ( V$DATAFILE ) will fail with RMAN-00600 [8064], because RMAN will try to restore files on the path stored in recovery catalog (RC_DATAFILE) as opposed to V$DATAFILE of production database.

Cloning a production database should be not be attempted with RMAN connected to recovery catalog, particularly when the path/name of datafiles are changed with SET NEW NAME...SWTICH DATAFILE.. command. It resyncs the catalog with new datafile path/name which leads to the difficulty in furhter restore. It is mentioned in Oracle documentation also :

http://download.oracle.com/docs/cd/B19306_01/backup.102/b14191/rcmrecov....

Now, the problem here is that we need to update the recovery catalog with correct file name as present in controlfile of production database to avoid any confusions.

SOLUTION

Option 1:

=======

UNREGISTER / REGISTER the database and catalog all backups :

RMAN> UNREGISTER DATABASE ;

RMAN> REGISTER DATABASE ;

RMAN> CATALOG START WITH <backup_path>\ ;

Option 2:

======

Change any property of datafiles, so that RMAN resync the schema information into recovery catalog. For example, resizing the datafile will resync the controlfile information into recovery catalog :

SQL> ALTER DATABASE DATAFILE <datafile_number> RESIZE <old_size+1> ;

In above SQL, the size of datafile is increased just by 1 byte.

Now, connect to RMAN with recovery catalog and resync catalog :

RMAN> CONNECT TARGET /

RMAN> CONNECT CATALOG <UN>/<PWD>@<TNS>

RMAN> RESYNC CATALOG ;

RMAN> REPORT SCHEMA ; # It should now show the correct path

Further RESTORE should succeed after updating the recovery catalog information with correct path/name of datafiles.

You are here

RMAN RESTORE fails with RMAN-00600 [8064]

RMAN RESTORE fails with RMAN-00600 [8064]