咨询微信： dbservice1234 7 x 24 在线支持！

首页

下载 DBRECOVER

RMAN RESTORE fails with RMAN-00600 [8064]

RMAN RESTORE fails with RMAN-00600 [8064]

Posted by PDSERVICE on 3月 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 :
 
 
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.