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.
DBRECOVER Recovery Options
For Oracle incidents, start with the DBRECOVER for Oracle trial to verify table visibility, row previews, and export readiness on copied datafiles. For MySQL and InnoDB incidents, DBRECOVER for MySQL is free software and can inspect.ibd files, ibdata1, and database directories locally.
When the case is urgent, preserve the original files first, work from copies, and contact paid emergency support with the database version, platform, error messages, file list, and recovery objective.