How do you recover a full DB using Arcserve with RMAN

[Bayvista]

We're testing a full disaster recovery scenario with Oracle database 10.2.0.1.0 on Windows Server 2003 SP2 using CA ARCserve v11.5 r3 for the MML. We're using RMAN without a repository database, so RMAN is configured to perform controlfile autobackups.

So far, we have recovered our server with the O/S and Oracle software ; We now wish to recover our database from the latest backup tape - This tape contains a full hot backup of the "TEST" database along with an autobackup of the controlfile and spfile.

So to start off with, we created a new instance & password file, as follows:

D:\oracle\Ora10gDB\bin\oradim.exe -new -sid TEST -startmode manual -spfile
D:\oracle\Ora10gDB\bin\oradim.exe -edit -sid TEST -startmode auto -srvcstart system

D:\oracle\Ora10gDB\bin\orapwd.exe file=D:\oracle\Ora10gDB\database\PWDTEST.ora password=mypassword force=y


Then in a command window :

C:> set oracle_sid=test
C:> rman target /

Recovery Manager: Release 10.2.0.1.0 - Production on Thu Apr 3 11:23:00 2008

Copyright (c) 1982, 2005, Oracle. All rights reserved.

connected to target database (not started)

RMAN> startup force nomount ;

startup failed: ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file 'D:\ORACLE\ORA10GDB\DATABASE\INITTEST.O
RA'

starting Oracle instance without parameter file for retrival of spfile
Oracle instance started

Total System Global Area 159383552 bytes

Fixed Size 1247828 bytes
Variable Size 58721708 bytes
Database Buffers 92274688 bytes
Redo Buffers 7139328 bytes


Well that message sounds promising - "starting Oracle instance without parameter file FOR RETRIEVAL OF SPFILE" - that's exactly what we want to do. So let's try to restore the SPFILE from the autobackup on tape. I actually know the exact name of the controlfile autobackup, so...

RMAN> run {
2> allocate channel ch_tape device type sbt ;
3> restore spfile to 'd:\backup\spfile' from 'c-1947840713-20080328-00' ;
4> }

allocated channel: ch_tape
channel ch_tape: sid=36 devtype=SBT_TAPE
channel ch_tape: MMS Version 0.0.0.0

Starting restore at 03-APR-08

channel ch_tape: autobackup found: c-1947840713-20080328-00
released channel: ch_tape
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 04/03/2008 11:29:21
ORA-19870: error reading backup piece c-1947840713-20080328-00
ORA-19507: failed to retrieve sequential file, handle="c-1947840713-20080328-00"
, parms=""
ORA-27007: failed to open file
ORA-19511: Error received from media manager layer, error text:
SBT error = 7009, errno = 0, sbtopen: can't connect with media manager

RMAN>exit;


If we look in the trace file for the MML, we see the following entry :

<11:29:20 :TID[5652]>: _ASFileRestore() failed, ASResult=-1. RMAN backup file \\BPNCSES11\dbaora8@RMAN\DUMMY@\c-1947840713-20080328-00 can't be found.

See where it says "DUMMY" in the trace file entry? That should say "TEST" ... it appears that when requesting a file from the MML, RMAN is passing the database instance name "DUMMY" instead of "TEST" - As a result, the MML builds an incorrect file spec, and inevitably cannot find the file. Thus it appears that we won't be able to recover an SPFILE from an autobackup without first creating a full database... bit of a catch 22 situation. Any ideas?

 

[karluk]

Interesting problem. Metalink note 372996.1 deals with a similar recovery scenario, except that they are recovering from a disk backup rather than tape. The script that they use when restoring the spfile is as follows.

RMAN> set dbid=<dbid>;
run { 
set controlfile autobackup format for device type disk to '<path>\%F'; 
restore spfile from autobackup; 
restore controlfile from autobackup; 
startup force mount 
}

I gather that you could modify this script by supplying the same controlfile autobackup format that was in effect when the backup was taken. Then your MML should be able to find the correct backup.