Still celebrating National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17


RMAN restore from disk with files in a new location

Posted on 2004-09-29
Medium Priority
Last Modified: 2011-08-18
Is it possible to restore from a backup set where the set is in a
different disk location from where it was originally created.
For example:
replace script test_full_recovery {
  allocate channel d1 type disk format '/backup/df_%d_t%t_s%s_p%p';
  allocate channel d2 type disk format '/backup2/df_%d_t%t_s%s_p%p';
  restore database;

The backup sets were created in the /u17/backup and /u18/backup
directories and the script give me the following error:
RMAN-10035: exception raised in RPC: ORA-19624: operation failed, retry
ORA-19505: failed to identify file
ORA-27037: unable to obtain file status
HP-UX Error: 2: No such file or directory
Additional information: 3
ORA-06512: at "SYS.X$DBMS_BACKUP_RESTORE", line 925
RMAN-10031: ORA-19624 occurred during call to

Is there any way to tell RMAN that the backup set is now in a new
location? This is Oracle9i.
BTW, this IS just a test and not a real recovery.
Question by:rsolomon
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
1 Comment

Accepted Solution

baonguyen1 earned 500 total points
ID: 12182976
Though this article is for restore a database on a different node, it can be applied to the same node with different location of the restored files

 The purpose of this document is to demonstrate a restore of an RMAN backup to  
a different host than the original target.

Restoring an RMAN Backup to Another Node
In certain circumstances, it may be desirable to restore a database from an RMAN
backup onto a machine other than the original host. For example, to recover  
data at a given point in time, or to duplicate a production instance.
The example assumes:
 - the target database is on host A
 - the database is to be restored onto host B
 - the directory structure of host B is different to host A
 - the ORACLE_SID will not change for the restored database
 - a recovery catalog is being used
 - the backups were carried out to disk (for illustrative purposes, and to  
   disassociate from any media manager specific issues)
The following steps are required:
 - backup the target on host A
 - list the datafile locations on host A
 - make the backup available to host B
 - make a copy of the init.ora available to host B
 - edit the init.ora to reflect directory structure changes
 - configure SQL*Net connectivity from host to the recovery catalog and  
   duplicated database
 - set up a password file for the duplicated database
 - startup nomount the duplicated database
 - RMAN restore the controlfile(s)
 - mount the database
 - restore and rename the datafiles
 - recover and open the database
These steps are expanded further below.  
1.0 Backup the Target on Host A
The target database needs to be backed up using RMAN.  
The following is one example of RMAN doing an online database backup. In this  
example, the backup sets are written to disk.
run {
allocate channel t1 type disk;
allocate channel t2 type disk;
allocate channel t3 type disk;
#backup the whole db
  tag whole_database_open
  format '/oracle/backups/BFS/df_%u'
# switch out of the current logfile
sql 'alter system archive log current';
#backup the archived logs
  archivelog all
  format '/oracle/backups/BFS/al_%u';
# backup a copy of the controlfile that contains records for the  
# other backups just made
  current controlfile  
  tag = cf1  
  format '/oracle/backups/BFS/cf_%u';
2.0 List Datafile Locations on Host A
The datafile numbers and location on host A are required. These datafile
locations will change on host B (see Section 7.3).
SVRMGR> select file#, name from v$datafile;
  file#   name
  -----   ------------------------------
  1       /oracle/OFA_base/u01/oradata/V805X/system01.dbf
  2       /oracle/OFA_base/u01/oradata/V805X/rbs01.dbf
  3       /oracle/OFA_base/u01/oradata/V805X/temp01.dbf
  4       /oracle/OFA_base/u01/oradata/V805X/tools01.dbf
  5       /oracle/OFA_base/u01/oradata/V805X/users01.dbf
  6       /oracle/OFA_base/u01/oradata/V805X/users02.dbf
  7       /oracle/OFA_base/u01/oradata/V805X/rbs02.dbf
  8       /oracle/OFA_base/u01/oradata/V805X/rcvcat.dbf
The log file names should also be recorded (see Section 7.4).
SVRMGR> select group#, member from v$logfile;
  group#  member
  -----   ------------------------------
  1       /oracle/OFA_base/u01/oradata/V805X/redo01.log
  2       /oracle/OFA_base/u01/oradata/V805X/redo02.log
  3       /oracle/OFA_base/u01/oradata/V805X/redo03.log
3.0 Make the Backups Available to Host B
3.1 Disk Backups
During restore, RMAN will expect the backup sets to be located in the same
directory as written to during the backup. For disk backups, the DBA can  
accomplish this in many ways:
   - set up an NFS directory, mounted on both host A and host B
   - create the same directory structure on host A and host B
   - use of symbolic links on host B
3.2 Tape Backups
The media management software must be configured such that host B is a  
media manager client, and can read the backup sets. The media management
vendor should be consulted for support on this issue.
4.0 init.ora on host B
The "init.ora" needs to be made available on host B. Any location specific  
parameters must be ammended. For example,
  - ifile
  - *_dump_dest
  - log_archive_dest*
  - control_files
5.0 SQL*Net configuration
If running rman from host A:
 a. connectivity to the catalog remains unchanged
 b. configure tnsnames.ora on host A to connect to duplicated db on host B
    configure listener.ora on host B to accept connections for duplicated
If running rman from host B:
 a. configure tnsnames.ora on host B to connect to catalog
    listener.ora on catalog host remains unchanged
 b. configure tnsnames.ora on host B to connect to duplicated db on host B
    configure listener.ora on host B to accept connections for duplicated
If running rman from host C (ie, neither host A or host B):
 a. connectivity to the catalog remains unchanged
 b. configure tnsnames.ora on host C to connect to duplicated db on host B
    configure listener.ora on host B to accept connections for duplicated
6.0 Setup Password File
In order to allow RMAN remote connections, a password file must be setup
for the duplicated database. For example,
orapwd file=$ORACLE_HOME/dbs/orapw$ORACLE_SID password=kernel
7.0 Recover Duplicated Database
7.1 startup nomount the database
    SVRMGR> startup nomount pfile=<location of init.ora>
7.2 restore the controlfile(s)
    For example,
      allocate channel c1 type disk;
      restore controlfile;
7.2 mount the database
    SVRMGR> alter database mount;
7.3 rename and restore the datafiles, and perform database recovery
    RMAN can be used to change the location of the datafiles from the location  
    on host A (see Section 2) to the new location on host B.
    For example,
    run {
     allocate channel c1 type disk;
     allocate channel c2 type disk;
     allocate channel c3 type disk;
     set newname for datafile 1 to '/oracle/datafiles/system01.dbf';
     set newname for datafile 2 to '/oracle/datafiles/rbs01.dbf';
     set newname for datafile 3 to '/oracle/datafiles/temp01.dbf';
     set newname for datafile 4 to '/oracle/datafiles/tools01.dbf';
     set newname for datafile 5 to '/oracle/datafiles/users01.dbf';
     set newname for datafile 6 to '/oracle/datafiles/users02.dbf';
     set newname for datafile 7 to '/oracle/datafiles/rbs02.dbf';
     set newname for datafile 8 to '/oracle/datafiles/rcvcat.dbf';
     restore database;
     switch datafile all;
7.4 recover and open the database
    Perform incomplete recovery:  
    SVRMGR> recover database using backup controlfile until cancel;
    Forward the database applying archived redo log files until you decide  
    to stop recovery by typing cancel at the prompt (assuming that you have
    required archived redo log files in the log_archive_dest directory)
    You may archive the source database redo log files and apply them at  
    the target database if required.
    SVRMGR> alter database open resetlogs;
    Note: this will create the online redo logs in the same location as that
    on host A. If this directory location does not exist, then this will fail
    ora-344 : unable to recreate online log <name>
    The workaround is to rename the logfiles prior to opening the database:
    SVRMGR> alter database rename file  
            '<host A location>' to '<host B location>';
    Alternatively, the logfile groups can be dropped and recreated. However,
    attempts to drop the current logfile group will fail. The current logfile
    must be renamed.

Featured Post

Veeam Task Manager for Hyper-V

Task Manager for Hyper-V provides critical information that allows you to monitor Hyper-V performance by displaying real-time views of CPU and memory at the individual VM-level, so you can quickly identify which VMs are using host resources.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Background In several of the companies I have worked for, I noticed that corporate reporting is off loaded from the production database and done mainly on a clone database which needs to be kept up to date daily by various means, be it a logical…
Using SQL Scripts we can save all the SQL queries as files that we use very frequently on our database later point of time. This is one of the feature present under SQL Workshop in Oracle Application Express.
This videos aims to give the viewer a basic demonstration of how a user can query current session information by using the SYS_CONTEXT function
This video shows how to recover a database from a user managed backup

722 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question