Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Methods for testing RMAN backups?

RE: Methods for testing RMAN backups?

From: Hostetter, Jay M <>
Date: Thu, 13 Oct 2005 11:14:35 -0400
Message-ID: <>

  Let me first say that I am sure there are other ways of doing this,
but this is a procedure that we setup when we first went to RMAN and it
has been working well for us.
  We have a test box seperate from production that is running the same
OS and version of Oracle (AIX running  We use RMAN to backup
to disk, then the disk backups are pulled to tape.  When I am moving a
database to the test box, I copy the disk backups over to the test
server (via rcp).  I create symbolic links on the test server so that it
appears as though the same backup file systems are on our test box as we
have on the production box (e.g. ln -s /backup1 /backupdev1).  I capture
the encrypted passwords of the users in the test database, then I shut
it down and delete the files associated with the database.  I then
startup nomount the database and use rman to restore on the test box
(ORACLE_SID is set to test database):
rman target uname/pwd_at_proddb <mailto:uname/pwd_at_proddb>  catalog
uname/pwd_at_prodcatalog <mailto:uname/pwd_at_prodcatalog>  auxiliary /
  I then run a script similar to the one below.  Since I include my
archivelog backups, I can recover my test database to any point in time.
After the database has been restored, I take it out of archivelog mode,
set the users passwords back, open up the schemas that contain objects,
change database links, change the global name (alter database rename
global_name to TESTDB.WORLD), depending on the app I may run some
scripts to scramble some sensitive data.
run {
#set until time '20050518070000';
set until scn 4230895133;
allocate auxiliary channel ch1 type disk;
allocate auxiliary channel ch2 type disk;
set newname for datafile 1 to '/t202/oradata/DEVDB/system01.dbf';
set newname for datafile 2 to '/t203/oradata/DEVDB/undotbs01.dbf';
set newname for datafile 3 to '/t202/oradata/DEVDB/tools01.dbf';
set newname for datafile 4 to '/t202/oradata/DEVDB/users01.dbf';
set newname for datafile 5 to '/t207/oradata/DEVDB/app_data_a01.dbf';
set newname for datafile 6 to '/t207/oradata/DEVDB/app_data_b01.dbf';
set newname for datafile 7 to '/t207/oradata/DEVDB/app_data_c01.dbf';
set newname for datafile 8 to '/t207/oradata/DEVDB/app_index_a01.dbf';
set newname for datafile 9 to '/t207/oradata/DEVDB/app_index_b01.dbf';
set newname for datafile 10 to '/t207/oradata/DEVDB/app_index_c01.dbf';
duplicate target database to DEVDB
group 1
('/t201/oradata/DEVDB/redo1a.log','/t202/oradata/DEVDB/redo1b.log') size
group 2
('/t201/oradata/DEVDB/redo2a.log','/t202/oradata/DEVDB/redo2b.log') size
group 3
('/t201/oradata/DEVDB/redo3a.log','/t202/oradata/DEVDB/redo3b.log') size
group 4
('/t201/oradata/DEVDB/redo4a.log','/t202/oradata/DEVDB/redo4b.log') size


[] On Behalf Of Marquez, Chris
Sent: Thursday, October 13, 2005 10:33 AM
To: Hostetter, Jay M;;
Subject: RE: Methods for testing RMAN backups?

I would say RESTORing and RECOVERing everything is not on the best test
of a backup (plan) but you own recovery skills too.

>> using RMAN with the auxiliary parameter
>> and our latest production database backup.

Wow, I never thought of that.
I have used "auxiliary" but only with creating a Standby DB even then
not often.
Can you explain it just a little more detail...maybe just a little
syntax too.

I assume you do not move (mv, scp, etc.) that prod RMAN backup around.
I can be seen from it location from both TST and PROD...or is it on

You roll logs to this way?


Chris Marquez
Oracle DBA

This e-mail message and any files transmitted with it are intended for the use of the individual or entity to which they are addressed and may contain information that is privileged, proprietary and confidential. If you are not the intended recipient, you may not use, copy or disclose to anyone the message or any information contained in the message. If you have received this communication in error, please notify the sender and delete this e-mail message. The contents do not represent the opinion of D&E except to the extent that it relates to their official business.

Received on Thu Oct 13 2005 - 10:18:21 CDT

Original text of this message