RMAN-03002: failure of recover command

Question

Hi all,
I am testing a new backup and restore mechanism of a 11.2 system in Linux. A third mirror of the disks from the database server has been split and mounted in a media server. An RMAN backup was taken then, on tape, using HP Data Protector. Then, in the media server again, I mounted all the disk groups and removed all the files from ASM via asmcmd. With everything cleared, I proceeded in doing the following:
1. Started up nomount using an old PFILE.
2. Initiated an RMAN session and SET DBID, connected to the target and the catalog. Restore the SPFILE in a PFILE.
3. Shutdow and started up nomount with PFILE the newly created file (edited it first to comment out CLUSTER_DATABASE parameter, as the media server is not configured for this).
4. Restored the contorl file. This was done successfully.
5. Restored the database. This was done successfully.
6. Mounted the database and attempted to recover it. I received the following error:
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 07/12/2013 09:42:24
RMAN-06094: datafile 1 must be restored
7. I attempted a recover from SQL*Plus; the error message was a little more helpful:
SQL> recover database using backup controlfile;
ORA-00283: recovery session canceled due to errors
ORA-01110: data file 1: '+BT1_A_SYSTEM/bt1_a/datafile/system.259.813148661'
ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
ORA-01110: data file 1: '+BT1_A_SYSTEM/bt1_a/datafile/system.259.813148661'
8. I checked my source database and the file name is as it appears above. But in the restored system, the file has a different name:
ASMCMD> pwd
+BT1_A_SYSTEM/BT1_A/DATAFILE
ASMCMD> ls -l SYSTEM*
Type      Redund  Striped  Time             Sys  Name
DATAFILE  UNPROT  COARSE   JUL 11 16:00:00  Y    SYSTEM.257.820514399
9. OK. I presume that this happened because we are using OMF. But, I was expecting RMAN to specify the full file names and thus restore them with their original names. The problem is now that the control file has the original file names, which cannot be found in the media server, where the restore took place. I am wondering if I should MOUNT the database after the control file restore and before I start the database restore, so RMAN might have the opportunity of renaming the file names in the control file.
Has anyone encountered this problem? I would appreciate some help.
Regards,
Takis.

Answer 1

That is correct Hemant. I latter realised my mistake.
When I mounted the database, the control file was opened. Then I repeated the restore. RMAN, this time was able to access the control file and rename dynamically the files, as they were restored and getting their new names.
So, I think, the correct sequence of events may be:
1, Check in ASM if the disk groups are mounted (lsdg). If not, mount the disk groups (alter diskgroup <dg_name> mount;).
2. Startup nomount (if no PFILE available, create a simple one with only db_name in it).
3. From RMAN, set DBID and then connect to target and catalog.
4. restore spfile to pfile from autobackup
5. restore control file(s) from autobackup
6. alter database mount
7. restore database
8. restore archivelog all
9. recover database
10. alter database open resetlogs
In my case, this worked, by enslarge. RMAN stopped when it run out of archived redo logs.
I then attempted, via SQL*Plus:
recover database using backup controlfile until cancel
When prompted, I typed: CANCEL
That was fine, but then, when I attempted:
SQL> alter database open resetlogs;
alter database open resetlogs
ERROR at line 1:
ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 525336576 bytes disk space from 2147483648 limit
So, I needed to increase the parameter db_recovery_file_dest_size which I did (in the pfile; luckily I had available space in the disk group). I shut down and started up (mount). Then:
SQL> alter database open resetlogs;
alter database open resetlogs
ERROR at line 1:
ORA-00392: log 24 of thread 2 is being cleared, operation not allowed
ORA-00312: online log 24 thread 2: '+BT1_A_RECO'
So:
SQL> alter database clear unarchived logfile group 24;
Database altered.
SQL> alter database open resetlogs;
Database altered.
SQL> select * from dual;
D
X
Happy days!
Regards,
Takis.