We use Veritas Netbackup 5.1 as the Media Management Software for creating our production tape backups. Yesterday, I successfully created a RMAN DUPLICATE database on a different host using these tape backups .I am documenting the procedure below
1)RMAN target = source database of the RMAN backups
2)duplicate database = destination database that needs to be created from the source database backup
3)auxiliary database = duplicate database
6)RMAN repository = separate schema (RMAN catalog) in a separate database that contains source database’s backup details
7)dev7 is the name of the duplicate database to be created
8)Media Manager Server = Netbackup Media Manager Server.
9)Media Manager Client = source database host
10)PROD = source database name
11)DEV = duplicate database name
12)RMANCT = RMAN catalog database name
13)RMANPROD = RMAN catalog repository schema name
CREATE DESTINATION DATABASE osuser and group SIMILAR to SOURCE DATABASE osuser and group
One of the requirements of RMAN duplication using VERITAS NETBACKUP is that the destination database's osuser and group should be similar to what it is in the source database node
e.g If source database ORACLE_HOME owner is oracle:dba, the destination database ORACLE_HOME owner should also be oracle:dba
MAKE BACKUP TAPES accessible to DESTINATION HOST
1)Contact your NETBACKUP system administrators to the source database BACKUP TAPES accessible to DESTINATION HOST
2)Verify by the following command
a) Login oracle@destination_db_host
b) /usr/openv/netbackup/bin/bplist -C source_db_host -t 4 -l -R /
The above bplist command should list all the backup sets that are in the RMAN catalog
Prepare Duplicate database
2)Copy the source database's initSID.ora to the destination host and add a new parameter DB_FILE_NAME_CONVERT. For e.g if the source database files are in /oracle/prod/d1 and /oracle/prod/d2 directories and if the corresponding restoration paths in the destination host are to be /oracle/dev/d1 and /oracle/dev/d2 respectively,
3)sqlplus '/ as sysdba'
5)Edit the $TNS_ADMIN/tnsnames.ora and add connection descriptors for the source database PROD and its catalog database RMANCT
Run the DUPLICATE command
RMAN always restores from the latest tape backups by default to create new database with the DUPLICATE command.
1)Login to oracle@destination_host
2)Connect to RMAN
connect target sys/***@prod
connect catalog rmanprod/****@rmanct
connect auxiliary /
3)Issue the Duplicate commands
allocate auxiliary channel t1 type 'SBT_TAPE';
allocate auxiliary channel t2 type 'SBT_TAPE';
SEND 'NB_ORA_SERV=media manager server, NB_ORA_CLIENT=source_host';
target database to dev
'/oracle/dev/logs/dev_log1.dbf' size 256M,
'/oracle/dev/logs/dev_log2.dbf' size 256M,
'/oracle/dev/logs/dev_log3.dbf' size 256M
4)Verify the dev alert log and the RMAN log /tmp/client/dev.log
5) The whole restore process will happen over the network depending on the network speed and the source database size
Restoration of only archive logs from RMAN
1) Login oracle@destination_host
2) select * from v$instance ( it should show ‘MOUNTED’ status)
3) shutdown immediate
4) Login oracle@source_host
5) Restore the archivelog files with a separate RMAN command.
connect target /
connect catalog rmanprod/****@rmanct
allocate channel t1 type 'SBT_TAPE';
set archivelog destination to '/home/oracle/';
from time "to_date('09/24/07 8:00:00', 'mm/dd/yy hh24:mi:ss')" until time "to_date('09/24/07 13:00:00', 'mm/dd/yy hh24:mi:ss')";
7)Verify the restored archive logfiles in /home/oracle/
8)Copy them to destination node using rcp or scp command
9)Login to destination node oracle@destination_host
10)Mount the destination database dev and recover manually using the 'recover database until cancel using backup controlfile' command
11)Type ‘cancel’ after applying the necessary archive logfiles to make the destination database consistent
12) alter database open resetlogs
13) Create the temporary tablespace
How to create a duplicate database until a specific time in the RMAN repository
The procedure remains the same except one more ‘set until’ command. The set until time command has to be put in the run block just before the duplicate command to create the duplicate database upto a specific point in time.
set until time= "to_date('mm/dd/yyyy hh24:mi:ss', 'MM/DD/YYYY HH24:MI:SS')";
Affect of Duplicate command on Recovery Catalog
There is no affect of duplication on the recovery catalog. RMAN generates a new DBID for the duplicate database. Unless this DBID is registered in the catalog, RMAN does not create or update any records for the newly created duplicate database.
It is not necessary to register the newly created duplicate database in the RMAN catalog unless the newly created duplicate database wants to use RMAN for its own backups
Precise information and good direction ..Many thanks to "DAILY DBA" to make "RMAN" so simple and easy. I hope you'll stay tuned ....
Thanks for the good notes...
Thanks for the DUPLICATE commands. I did not know the requirement that source and destination osuser should be the same.
Very good steps. I am going to try this and let you know how it goes. Just in case if you: do you know how to make the backups available to the destination host?
Is your backup on disk or tape ? You need to mount your tapes to the destination host (the tape management software should be able to browse the backup on the destination host).
If it is a backup on disk, then all you have to do is copy the backup from source to destination. Make sure that the directory path is exactly similar to the one on source host.
Srinivas, my backup is on tape. I spoke to my sys/network admin today and he mentioned the tape should all be already accessible because they have not removed it from the library. I am going to try that tomorrow. Few months back when I tried, i always recieved this error
RMAN-06025: no backup of log thread 1 seq 1 lowscn 6032794662676 found to resto
May be I was missing some other steps. I will follow your steps and see if I get the same error. In cany case, I will let you know how it goes.
Thanks for your quick reply.
The whole duplication did work and it failed at the recovery part. when i copied the archivelog & started manual recovery, it did not look like it needed any archivelogs.
is there any way to fix the recovery failure?
Did you open the database successfully ? or currently you are still having a recovery problem ?
Please paste the errors. You can add me in Google Talk incase you need immediate help.
Srinivas, Your success story for duplication to a new host is inspiring. Now I try to do the same thing. but keep getting error message from "bplist" output:
EXIT STATUS 135: client is not validated to perform the requested operation.
Do you know what could be wrong in Netbackup configuration, any document can follow for backups available to the destination host?
Thanks a lot.
Are you sure you have the required pre-reqs setup ?
1) Destination host and source host must be having the same user id.
Are you also the netbackup administrator in your org ? If not, you can pass on this error message to your netbackup admin. They should be able to resovle this for this. So this issue not really a database issue at this stage.
I am sure I have the required pre-reqs setup. I know the problem is in netbackup side. We don't have netbackup administrator, our unix/sys admin don't understand either. so I will pass the error message from "bplist" output to him for SR from netbackup.
Thanks for help.
Srinivas, The duplicate worked and I did not need to copy archivelogs from source machine. I just did alter database open resetlogs and it worked. My question was to ask if there is any workaround you know where it does not fail during the recovery.
Sorry for the late reply. Thanks a lot for your help.
Each failure case can be different and I will have to deal case by case.
Good that you have made the duplicate to work.
I have to restore PROD to test, I mean the userid are different , is there any way we can do that.
I can access the PROD backups from Test box.
Thanks in advance .
Appriciate your help.
Post a Comment