Home » RDBMS Server » Backup & Recovery » RMAN Recovery Testing, Advice on Strategy
icon6.gif  RMAN Recovery Testing, Advice on Strategy [message #109777] Mon, 28 February 2005 14:56 Go to next message
thomasm
Messages: 1
Registered: February 2005
Location: St. Petersburg, FL
Junior Member
RMAN Recovery Testing Advice on Strategy


ISSUE:
Implementng testing RMAN on AIX NODE-A, Production database
SID=PROD1. Succsessfully hot backup using RMAN and successfully
backing up archivelog using rman for this Production database. I
have a Testing node NODE-B (SID=TEST1) on which I want to test
recovery.

ENVIRONMENT:
AIX 5.1 ML4 Oracle 8.1.7.4.0. RMAN being run from Veritas.
Using IBM 3584 Tape library and have Access to FAStT for backup
media.

We are in a full service medical facility, so cold backup has not
been run for some time. Hot backups are run daily, and archive
logs daily.

1) How do I get RMAN to restore PROD database to existing TEST
database on the other node? Will it not complain that I am
restoring to database other than PROD?


2) Are there changes I can make to fool RMAN since database IDs
are different?


3) Will I not want to make new incarnation of my TEST database so
resoration will not require access to long history of archive
logs?

4) I am also looking at possibly using RMAN DUPLICATE command.


Any advice is appreciated.
Mark Thomas
Re: RMAN Recovery Testing, Advice on Strategy [message #109779 is a reply to message #109777] Mon, 28 February 2005 15:45 Go to previous messageGo to next message
Mahesh Rajendran
Messages: 10707
Registered: March 2002
Location: oracleDocoVille
Senior Member
Account Moderator
PLEASE.
FIRST READ DOCUMENTATION.
ALL STEPS are clearly given.
>>1) How do I get RMAN to restore PROD database to existing TEST
>>database on the other node? Will it not complain that I am
>>restoring to database other than PROD?

You can duplicate ( clone) PROD to TEST.
It will NOT complain as you clearly say to RMAN that
PROD is target and
TEST is auxillary database.

>>2) Are there changes I can make to fool RMAN since database IDs
>>are different?
Nothing. Duplicate command will take care of that.

rman> Duplicate target database to TEST
pfile=/../../initTEST.ora
..
..

>>3) Will I not want to make new incarnation of my TEST database so
>>resoration will not require access to long history of archive
>>logs?

with 9i and above you can easily reset the incarnation.
But to avaoid that situtaion ( THis what i do),
I have different RMAN users for different purpose.

user backup_prod -- to backup prod
user restore_prod -- to restore prod ( in case of disaster)
user clone_prod_test-- to clone prod to test ( routine on demand cloning).

By this, YOU always have 2 fallback users (backup_prod and restore_prod) that still look into PROD. after backing up every day , register/ resync these two users and clone_prod_test to the target database (PROD), so that at any point you can start the cloning.
after cloning is done and everything is all set (using clone_prod_test) now resync /register clone_prod_test back to PROD.

>>4) I am also looking at possibly using RMAN DUPLICATE command.
It is the way to go!

write seperate scripts for all users ( handling different scenarios).
TEST IT, again and again and again.
ANd do it frequently even after you are in production mode
Re: RMAN Recovery Testing, Advice on Strategy [message #112794 is a reply to message #109777] Tue, 29 March 2005 07:36 Go to previous messageGo to next message
valcindor@yahoo.com
Messages: 4
Registered: April 2001
Location: France
Junior Member
Is it possible with RMAN to have a replication of a PROD database, byte by byte of the data files in order to do performance tests for example ?
Re: RMAN Recovery Testing, Advice on Strategy [message #112799 is a reply to message #112794] Tue, 29 March 2005 08:09 Go to previous messageGo to next message
Mahesh Rajendran
Messages: 10707
Registered: March 2002
Location: oracleDocoVille
Senior Member
Account Moderator
I dont understand what you are looking into.
REPLICATION is very different concept.
RMAN has nothing to do with it.
with replication, the changes made in one or more sties are propogated betwen the sites synchronously / asynchronously.

RMAN duplication is something where you
first backup the ProdDB
restore prodDB to a testDB in samemachine / remote machine.
Re: RMAN Recovery Testing, Advice on Strategy [message #112806 is a reply to message #112799] Tue, 29 March 2005 08:37 Go to previous messageGo to next message
valcindor@yahoo.com
Messages: 4
Registered: April 2001
Location: France
Junior Member
You are right. What I meant is to duplicate the production database in order to perform tests to verify that tuning done on the test database will have positive effect on the production database.
If RMAN can't do it (and I think it does not) do you know of any other tool that would duplicate data files, block by block.
I hope this is clearer.
Thanks
Re: RMAN Recovery Testing, Advice on Strategy [message #112811 is a reply to message #112806] Tue, 29 March 2005 08:46 Go to previous messageGo to next message
Mahesh Rajendran
Messages: 10707
Registered: March 2002
Location: oracleDocoVille
Senior Member
Account Moderator
in the previous posting, i just told that RMAN can do the duplication.

REfer to RMAN documentation.
DUplication / cloning is nothing by restoring the backupsets of prodDB into a new database TestDB.
It will re-create the testDB as an exact copy of prodDB.
Since RMAN needs only the backupsets to do this, your prodDB is virtually UNTOUCHED during this operation.

>>perform tests to verify that tuning done on the test database will have positive effect on the production database

One cannot predict 100% accurate.
THere might be difference in the hardware, load etc.
Re: RMAN Recovery Testing, Advice on Strategy [message #112819 is a reply to message #109777] Tue, 29 March 2005 09:28 Go to previous message
valcindor@yahoo.com
Messages: 4
Registered: April 2001
Location: France
Junior Member
Thanks for your remarks
Previous Topic: Issue about import and export database!
Next Topic: what should be in cold backup
Goto Forum:
  


Current Time: Thu Mar 28 14:27:52 CDT 2024