Email: service@parnassusdata.com 7 x 24 online support!
RMAN RESTORE fails with RMAN-00600 [8064]
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 :
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.