Oracle RMAN Restore to the Same Machine as the Original Database

Posted in: Technical Track

Among the most critical but often most neglected database administration tasks is testing restore from backup. But sometimes, you don’t have a test system handy, and need to test the restore on the same host as the source database. In such situations, the biggest fear is overwriting the original database. Here is a simple procedure you can follow, which will not overwrite the source.

  1. Add an entry to the oratab for the new instance, and source the new environment:
    oracle$ cat >> /etc/oratab <<EOF
    > foo:/u02/app/oracle/product/11.2.0/dbhome_1:N
    > EOF
    
    oracle$ . oraenv
    ORACLE_SID[oracle]? foo
    The Oracle base remains unchanged with value /u02/app/oracle
  2. Create a pfile and spfile with a minimum set of parameters for the new instance. In this case the source database is named ‘orcl’ and the new database will have a DB unique name of ‘foo’. This example will write all files to the +data ASM diskgroup, under directories for ‘foo’. You could use a filesystem directory as the destination as well. Just make sure you have enough space wherever you plan to write:
    oracle$ cat > $ORACLE_HOME/dbs/initfoo.ora <<EOF
    > db_name=orcl
    > db_unique_name=foo
    > db_create_file_dest=+data
    > EOF
    
    oracle$ sqlplus / as sysdba
    SQL*Plus: Release 11.2.0.3.0 Production on Wed Apr 9 15:35:00 2014
    Copyright (c) 1982, 2011, Oracle.  All rights reserved.
    Connected to an idle instance.
    
    SQL> create spfile from pfile;
    File created.
    
    SQL> exit
    Disconnected
  3. Now, using the backup pieces from your most recent backup, try restoring the controlfile only. Start with the most recently written backup piece, since RMAN writes the controlfile at the end of the backup. It may fail once or twice, but keep trying backup pieces until you find the controlfile:
    oracle$ ls -lt /mnt/bkup
    total 13041104
    -rwxrwxrwx 1 root root      44544 Apr  4 09:32 0lp4sghk_1_1
    -rwxrwxrwx 1 root root   10059776 Apr  4 09:32 0kp4sghi_1_1
    -rwxrwxrwx 1 root root 2857394176 Apr  4 09:32 0jp4sgfr_1_1
    -rwxrwxrwx 1 root root 3785719808 Apr  4 09:31 0ip4sgch_1_1
    -rwxrwxrwx 1 root root 6697222144 Apr  4 09:29 0hp4sg98_1_1
    -rwxrwxrwx 1 root root    3647488 Apr  4 09:28 0gp4sg97_1_1
    
    $ rman target /
    Recovery Manager: Release 11.2.0.3.0 - Production on Wed Apr 9 15:37:10 2014
    Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
    connected to target database (not started)
    
    RMAN> startup nomount;
    Oracle instance started
    Total System Global Area     238034944 bytes
    Fixed Size                     2227136 bytes
    Variable Size                180356160 bytes
    Database Buffers              50331648 bytes
    Redo Buffers                   5120000 bytes
    
    RMAN> restore controlfile from '/mnt/bkup/0lp4sghk_1_1';
    Starting restore at 09-APR-14
    using target database control file instead of recovery catalog
    allocated channel: ORA_DISK_1
    channel ORA_DISK_1: SID=1 device type=DISK
    channel ORA_DISK_1: restoring control file
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03002: failure of restore command at 04/09/2014 15:42:10
    ORA-19870: error while restoring backup piece /mnt/bkup/0lp4sghk_1_1
    ORA-19626: backup set type is archived log - can not be processed by this conversation
    
    RMAN> restore controlfile from '/mnt/bkup/0kp4sghi_1_1';
    Starting restore at 09-APR-14
    using target database control file instead of recovery catalog
    allocated channel: ORA_DISK_1
    channel ORA_DISK_1: SID=19 device type=DISK
    channel ORA_DISK_1: restoring control file
    channel ORA_DISK_1: restore complete, elapsed time: 00:00:07
    output file name=+DATA/foo/controlfile/current.348.844443549
    Finished restore at 09-APR-14

    As you can see above, RMAN will report the path and name of the controlfile that it restores. Use that path and name below:

    RMAN> sql "alter system set
    2>  control_files=''+DATA/foo/controlfile/current.348.844443549''
    3>  scope=spfile";
    
    sql statement: alter system set 
    control_files=''+DATA/foo/controlfile/current.348.844443549'' 
    scope=spfile
  4. Mount the database with the newly restored controlfile, and perform a restore to the new location. The ‘set newname’ command changes the location that RMAN will write the files to the db_create_file_dest of the new instance. The ‘switch database’ command updates the controlfile to reflect the new file locations. When the restore is complete, use media recovery to apply the archived redologs.
    RMAN> startup force mount
    Oracle instance started
    database mounted
    Total System Global Area     238034944 bytes
    Fixed Size                     2227136 bytes
    Variable Size                180356160 bytes
    Database Buffers              50331648 bytes
    Redo Buffers                   5120000 bytes
    
    RMAN> run {
    2> set newname for database to new;
    3> restore database;
    4> }
    
    executing command: SET NEWNAME
    Starting restore at 09-APR-14
    allocated channel: ORA_DISK_1
    channel ORA_DISK_1: SID=23 device type=DISK
    channel ORA_DISK_1: starting datafile backup set restore
    channel ORA_DISK_1: specifying datafile(s) to restore from backup set
    channel ORA_DISK_1: restoring datafile 00002 to +data
    channel ORA_DISK_1: reading from backup piece /mnt/bkup/0hp4sg98_1_1
    channel ORA_DISK_1: piece handle=/mnt/bkup/0hp4sg98_1_1 tag=TAG20140404T092808
    channel ORA_DISK_1: restored backup piece 1
    channel ORA_DISK_1: restore complete, elapsed time: 00:01:35
    channel ORA_DISK_1: starting datafile backup set restore
    channel ORA_DISK_1: specifying datafile(s) to restore from backup set
    channel ORA_DISK_1: restoring datafile 00001 to +data
    channel ORA_DISK_1: restoring datafile 00004 to +data
    channel ORA_DISK_1: restoring datafile 00005 to +data
    channel ORA_DISK_1: reading from backup piece /mnt/bkup/0ip4sgch_1_1
    channel ORA_DISK_1: piece handle=/mnt/bkup/0ip4sgch_1_1 tag=TAG20140404T092808
    channel ORA_DISK_1: restored backup piece 1
    channel ORA_DISK_1: restore complete, elapsed time: 00:01:05
    channel ORA_DISK_1: starting datafile backup set restore
    channel ORA_DISK_1: specifying datafile(s) to restore from backup set
    channel ORA_DISK_1: restoring datafile 00003 to +data
    channel ORA_DISK_1: reading from backup piece /mnt/bkup/0jp4sgfr_1_1
    channel ORA_DISK_1: piece handle=/mnt/bkup/0jp4sgfr_1_1 tag=TAG20140404T092808
    channel ORA_DISK_1: restored backup piece 1
    channel ORA_DISK_1: restore complete, elapsed time: 00:00:55
    Finished restore at 09-APR-14
    
    RMAN> switch database to copy;
    
    datafile 1 switched to datafile copy "+DATA/foo/datafile/system.338.844531637"
    datafile 2 switched to datafile copy "+DATA/foo/datafile/sysaux.352.844531541"
    datafile 3 switched to datafile copy "+DATA/foo/datafile/undotbs1.347.844531691"
    datafile 4 switched to datafile copy "+DATA/foo/datafile/users.350.844531637"
    datafile 5 switched to datafile copy "+DATA/foo/datafile/soe.329.844531637"
    
    RMAN> recover database;
    
    Starting recover at 09-APR-14
    using channel ORA_DISK_1
    starting media recovery
    archived log file name=/u02/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_25_841917031.dbf thread=1 sequence=25
    archived log file name=/u02/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_26_841917031.dbf thread=1 sequence=26
    archived log file name=/u02/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_27_841917031.dbf thread=1 sequence=27
    media recovery complete, elapsed time: 00:00:01
    Finished recover at 09-APR-14
    
    RMAN> exit
    
    Recovery Manager complete.
  5. Before opening the database, we need to re-create the controlfile so that we don’t step on any files belonging to the source database. The first step is to generate a “create controlfile” script, and to locate the trace file where it was written:
    $ sqlplus / as sysdba
    SQL*Plus: Release 11.2.0.3.0 Production on Wed Apr 16 10:56:28 2014
    Copyright (c) 1982, 2011, Oracle.  All rights reserved.
    Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
    
    SQL> alter database backup controlfile to trace;
    Database altered.
    
    SQL> select tracefile
      2  from v$session s,
      3       v$process p
      4  where s.paddr = p.addr
      5  and s.audsid = sys_context('USERENV', 'SESSIONID');
    TRACEFILE
    ----------------------------------------------------------
    /u02/app/oracle/diag/rdbms/foo/foo/trace/foo_ora_19168.trc
    
    SQL> exit
    Disconnected from Oracle Database 11g Enterprise Edition
  6. Next, we need to edit the controlfile creation script so that all we have left is the “create controlfile … resetlogs” statement, and so that all file paths to the original database are removed or changed to reference the db_unique_name of the test database.Below is a pipeline of clumsy awks I created that creates a script called create_foo_controlfile.sql. It should take care of most permutations of these trace controlfile scripts.
    $ sed -n '/CREATE.* RESETLOGS/,$p' /u02/app/oracle/diag/rdbms/foo/foo/trace/foo_ora_18387.trc | \
    > sed '/.*;/q' | \
    > sed 's/\(GROUP...\).*\( SIZE\)/\1\2/' | \
    > sed 's/orcl/foo/g' | \
    > sed 's/($//' | \
    > sed 's/[\)] SIZE/SIZE/' | \
    > grep -v "^    '" > create_foo_controlfile.sql

    If it doesn’t work for you, just edit the script from your trace file, so that you end up with something like this:

    CREATE CONTROLFILE REUSE DATABASE "ORCL" RESETLOGS  ARCHIVELOG
        MAXLOGFILES 16
        MAXLOGMEMBERS 3
        MAXDATAFILES 100
        MAXINSTANCES 8
        MAXLOGHISTORY 292
    LOGFILE
      GROUP 1 
      SIZE 50M BLOCKSIZE 512,
      GROUP 2 
      SIZE 50M BLOCKSIZE 512,
      GROUP 3 
      SIZE 50M BLOCKSIZE 512
    -- STANDBY LOGFILE
    DATAFILE
      '+DATA/foo/datafile/system.338.845027673',
      '+DATA/foo/datafile/sysaux.347.845027547',
      '+DATA/foo/datafile/undotbs1.352.845027747',
      '+DATA/foo/datafile/users.329.845027673',
      '+DATA/foo/datafile/soe.350.845027673'
    CHARACTER SET WE8MSWIN1252
    ;
  7. The next step is to use the above script to open the database with the resetlogs option on a new OMF controlfile:
    $ sqlplus / as sysdba
    SQL*Plus: Release 11.2.0.3.0 Production on Wed Apr 16 10:56:28 2014
    Copyright (c) 1982, 2011, Oracle.  All rights reserved.
    Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
    
    SQL> alter system reset control_files scope=spfile;
    System altered.
    
    SQL> startup force nomount
    ORACLE instance started.
    
    Total System Global Area  238034944 bytes
    Fixed Size                  2227136 bytes
    Variable Size             180356160 bytes
    Database Buffers           50331648 bytes
    Redo Buffers                5120000 bytes
    
    SQL> @create_foo_controlfile
    Control file created.
    
    SQL> select value from v$parameter where name = 'control_files';
    VALUE
    -------------------------------------------
    +DATA/foo/controlfile/current.265.845031651
    
    SQL> alter database open resetlogs;
    Database altered.
  8. Last but not least, don’t forget to provide a tempfile or two to the temporary tablespaces:
    SQL> alter tablespace temp
      2  add tempfile size 5G;
    Tablespace altered.
email
Want to talk with an expert? Schedule a call with our team to get the conversation started.

About the Author

Jeremiah Wilton has over eighteen years of Oracle database administration and systems architecture experience. As Amazon.com’s first database administrator, he helped lead Amazon.com’s database group from the pre-IPO period through the company’s years of exponential growth. He now works for Pythian, a leader in remote database administration for Oracle, Oracle Applications, SQL Server and MySQL. Jeremiah also teaches the Oracle Certificate Program at the University of Washington. At Oracle OpenWorld in 2001, Oracle Education honored Jeremiah as one of the first eight Oracle Certified Masters in the world. Jeremiah is a member of the OakTable, and co-author of the Oak Table’s Oracle Insights. He has presented at numerous conferences and user groups, including Oracle OpenWorld, Collaborate! and UKOUG, and is the author of a variety of technical whitepapers and articles.

43 Comments. Leave new

Andriy Dmytrenko
April 11, 2014 2:08 pm

Nice article but you forgot the block change tracking file. If it has been enabled than you probably crashed the original database.

Reply
Jeremiah Wilton
April 11, 2014 2:42 pm

Andriy, great point and thanks. Fixing it right away. -JW

Reply
Jeremiah Wilton
April 11, 2014 3:20 pm

Fixed! -JW

Reply

Hi Jeremiah,
what actually has been fixed in block change tracking matter ?
Regards
GregG

Reply

Oh I see now. Sorry about that .
GregG

Reply
Andriy Dmytrenko
April 14, 2014 2:12 am

Thanks!

Reply
ThomasMullahy
April 11, 2014 5:44 pm

Great post Jeremiah! Thanks for the excellent, vetted example. Many DBAs would probably rather risk an untested restore than risk potentially damaging their customers live Production system by accidently stepping on a live db file.

Reply
oracleman consulting
April 14, 2014 9:41 am

Thanks for posting. Yes, most DBAs would rate this task as ‘risky’

Reply

It works fine until I get to “startup force mount” – I get an error:
ORA-01103: database name ‘UW01’ in control file is not ‘FOO’

Reply
Jeremiah Wilton
April 14, 2014 1:35 pm

Hi Jimmy how’s it going? The reason you probably got an error is because the example is for a source DB named ORCL and a test DB named FOO. What is the DB_NAME of your source (probably UW01, right – sounds kinda familiar), and what values did you use in the pfile you created in step 2? -Jeremiah

Reply

Thanks, Jeremiah! You are correct – I made db_name and db_unique_name both FOO. My bad.

Reply
Jeremiah Wilton
April 17, 2014 10:00 am

I reworked the end of this procedure to include a ‘create controlfile’ step. Previously, I was using ‘alter database rename …’ to change the controlfile entries for the redologs and block change tracking file. It turns out that if the source database used OMF, the ‘alter database rename …’ statement can physically delete the original file. If we completely re-create the controlfile, then we remove the risk of OMF deleting the source DB files.

Doing a controlfile re-create seems a little old-school to me. My future plans for this procedure include tracing an RMAN duplicate to see if I can use dbms_backup_restore procedures and functions to more neatly accomplish some of the manual steps such as controlfile re-creation.

Reply

When you are creating new control file CREATE CONTROLFILE REUSE DATABASE “ORCL” RESETLOGS ARCHIVELOG
this should probably be “FOO” instead of ORCL

Reply

Instead of using alter database backup controlfile to trace and having to look for it, I have been using alter database backup controlfile to trace as ‘/tmp/cf_foo.sql’

Awesome POW.

Reply
Suresh Karthikeyan
May 22, 2014 11:35 pm

Good point Michael, never seen this command before…

Reply
Kirill Richine
June 28, 2014 6:35 pm

Nice article,
I think this command in 3 is not necessary since you started nomount from spfile:

RMAN> sql "alter system set
2> control_files=''+DATA/foo/controlfile/current.348.844443549''
3> scope=spfile";

I believe rman restore controlfile already does it implicitly

Reply

correct. if your pfile says: “control_files=’+DATA/foo/controlfile/controlfile_foo.ctl'”

then a “restore controlfile” should restore the controlfile to that exact location and handle an alias to the name.

Reply
Robert Freeman
June 30, 2014 12:28 pm

Hey Jeremiah… I can’t seem to find a current email address for you. Can you give me a shout at [email protected] or [email protected]… please. :)

Robert

Reply

Excellent article Jeremiah … exactly the kinda stuff I was looking for. Thanks for sharing.

Reply

Hey Jeremiah .. great artcile ..
Was wondering why would you use source DB name in create controlfile “CREATE CONTROLFILE REUSE DATABASE “ORCL”” ? Shouldnt it be FOO ?

Reply

Yup.. That happened because ‘s/orcl/foo/g’ | only checks for lowercase name.
Nice article.

Reply

What if I want the new DB name be changed to FOO ?

Reply

excellent.. this is so helpful.

Reply

I am having this error during recover. Is it using the source archive destination?
——————-
RMAN> recover database;

Starting recover at 21-MAY-15
using channel ORA_DISK_1

starting media recovery

archived log for thread 1 with sequence 1427 is already on disk as file /u02/oradata/TWMDB/redo02.log
archived log for thread 1 with sequence 1428 is already on disk as file /u02/oradata/TWMDB/redo03.log
archived log for thread 1 with sequence 1429 is already on disk as file /u02/oradata/TWMDB/redo01.log
unable to find archived log
archived log thread=1 sequence=1422
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 05/21/2015 12:45:58
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 1422 and starting SCN of 147498034

———————

Reply
Evandro Giachetto
June 16, 2015 10:20 am

Seems like your archivelog is not part of your backup backupset.
Try to find out where this archivelog is located by running this:
rman target /
list archivelog from logseq=1422 until logseq=1422;

If you do not find it, try searching in your backups.
rman target /
list backup of archivelog from logseq=1422 until logseq=1422;

If this is part of the backup, restore it:
rman target /
restore archivelog from logseq=1422 until logseq=1422;

With the archive in place:
rman target /
recover database until sequence 1422;

It may asks for aditional archivelogs if required.

Sometimes, it requests for an archivelog that wasn’t archive yet. If you check on the v$log, you’ll see that the sequence it requests was not archived yet (Usually when you run a backup without switching archivelog first).

In this case, run a
alter system switch logfile;

Wait for it to archive that redolog then you have it.

If this is a clone in a new server, then you may not be able to switch logile. In that case, query the v$logfile to findout the location of the needed logfile then

rman target /
recover database until cancel;

when it requests for the location of the archivelog that contains sequence, inform the location of your logfile.

I hope it helps.

Reply
Evandro Giachetto
June 16, 2015 3:05 pm

What does the ‘set newname for database to new;’ mean?

Is by any chance ‘new’ a word that need to be replaced by any other reference?

Reply

Excellent article…Can you tell me the steps involved for Rman restore to different machine

Reply
Anwar Hussaini
February 4, 2016 4:40 pm

getting this error, asm is being shared b/w node 1 and 2 on exadata
channel ORA_DISK_1: restoring control file
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 02/04/2016 15:38:46
ORA-19870: error while restoring backup piece /tmp/ux66nfs/oracle/rman/duptest/ora_ctl_PRITEST_2192264953_20160204_902935511_186_5qqt3cun_1_1.bak
ORA-19504: failed to create file “+DATAC1”
ORA-17502: ksfdcre:4 Failed to create file +DATAC1
ORA-15001: diskgroup “DATAC1” does not exist or is not mounted
ORA-15204: database version 11.2.0.0.0 is incompatible with diskgroup DATAC1

RMAN> exit
thanks
anwar

Reply
Krishna prasad
January 9, 2019 4:24 am

Please add below parameter in pfile in step2

compatible=11.2.0.4.0

Reply

I checked in Oracle docs but could not found so asking .
Is “set newname for database to new;” available in 10.2.0.4 as well or it is new for 11G. This seems to be very good and avoid writing set newname for every files.

Reply

Can u tell me , Is it possible to restore the same database on the same host to a new name ?

Reply

Is it possible to restore the same database in the same host to a new name?

Reply
Rencontre adultère
February 13, 2017 3:41 am

Thanks for finally writing about >Oracle RMAN restore to the same machine
as original database <Liked it!

Reply

Thanks for the great info! There have been multiple occasions where I have needed this, but wouldn’t a duplicate database command be simpler for most use cases? By default, it will grab whatever latest backup and apply as much incremental/archivelog data as possible, but you could also supply an until clause to test certain data (provided you have the necessary control files).

Start the FOO database nomount using an spfile that was fully configured the way you want for FOO, and run the RMAN statements below. If block change tracking was turned on for ORCL, you’ll have to log into the new database and turn it off for FOO while RMAN is running the restore part of the duplicate.

connect auxiliary /
run {
allocate auxiliary channel ch1 device type disk;
allocate auxiliary channel ch2 device type disk;
duplicate database to FOO backup location ‘/my/folder/containing/rman/backup/files/’
}

Reply

So which database you are connected to and which one is auxiliary?

Reply

I wanted to point out that you can also fully rename the database in this process.

In your create controlfile command, instead of just ‘reuse database “ORCL” resetlogs’, it should be ‘reuse set database “FOO” resetlogs’. Below is what the first line in the example should look like.
CREATE CONTROLFILE REUSE SET DATABASE “FOO” RESETLOGS ARCHIVELOG

Before running ‘startup force nomount’, run ‘alter system set db_name=FOO scope=spfile’.

Reply
Daniel Andrade Costa Silva
December 27, 2018 7:12 am

This helped me with the ORA-09968 problem (unable to lock file) when trying to create the new control file. Thank you very much!!!!!!!!!!

Reply

Is it not necessary to set up this while restoring RAC DataBase
*.cluster_database=false

Reply

Excellent article. Just wanted to know where is Block change tracking point addressed in the process?

Reply

Thank you for your feedback. Unfortunately the author of the post is no longer with Pythian.

Reply

Excellent article and great explanation of each and every step. I am having a trouble with ‘switch database to copy’ command:
RMAN> switch database to copy;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of switch to copy command at 09/15/2018 13:48:39
ORA-19571: datafile copy RECID 13 STAMP 986905809 not found in control file

RMAN>

Quick help will be highly appreciated.

Reply

Hi Jeremiah,

I have tried to restore the same database on same machine with db_unique_name as “TESTDEV”. But, while re-creating the controlfile am facing issues.

SQL> @cr8_cntrl_testdev.sql
CREATE CONTROLFILE REUSE DATABASE “SDLCDEV” RESETLOGS ARCHIVELOG
*
ERROR at line 1:
ORA-01503: CREATE CONTROLFILE failed
ORA-01158: database already mounted

Could you please help me here ?..

Thanks & Regards
Rajasekhar. B

Reply

Hi, Jeremiah

I have from error:
SQL> @cr8_cntrl_testdev.sql
CREATE CONTROLFILE REUSE DATABASE “SDLCDEV” RESETLOGS ARCHIVELOG
*
ERROR at line 1:
ORA-01503: CREATE CONTROLFILE failed
ORA-01158: database already mounted

Could you please help me here ?..

Reply

Leave a Reply

Your email address will not be published. Required fields are marked *