Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

backing up rac cluster oracle databases

Status
Not open for further replies.

ess07

MIS
Aug 23, 2007
11
US
Legato 7.4.4
Networker module for oracle 4.5



Please note that it's not the case that backups older than a certain date are not showing up. It's got alternating stretches of what was backed up on node 1 vs. node 2. If I run a crosscheck on node 1, it will only see the backups that were done on node 1. If I run a crosscheck on node 2, it will only see the backups that were done on node 2. This is the case even with NSR_CLIENT specified.
4/11-4/15 node 2
4/16-5/19 node 1
5/20-6/2 node 2
6/3-6/18 node 1
6/19-6/24 node 2

Here is the daily script:
run {
allocate channel oem_disk_backup device type disk;
recover copy of database with tag 'ORA\$OEM_LEVEL_0';
backup incremental level 1 cumulative copies=1 for recover of copy with tag 'ORA\$OEM_LEVEL_0' database;
release channel oem_disk_backup;
allocate channel oem_sbt_backup1 type 'SBT_TAPE' format '%U' parms 'ENV=(NSR_DATA_VOLUME_POOL=oraclebackup1,NSR_DATA_VOLUME_POOL1=oraclebackup2,NSR_CLIENT=gendev)';
backup archivelog all not backed up;
backup backupset all not backed up since time 'SYSDATE-1';
}
allocate channel for maintenance device type 'SBT_TAPE' parms 'ENV=(NSR_DATA_VOLUME_POOL=oraclebackup1,NSR_DATA_VOLUME_POOL1=oraclebackup2,NSR_CLIENT=gendev)';
delete noprompt obsolete recovery window of 75 days device type 'SBT_TAPE';
Here is the weekly script:
run {
allocate channel oem_disk_backup device type disk;
recover copy of database with tag 'ORA\$OEM_LEVEL_0';
backup incremental level 1 cumulative copies=1 for recover of copy with tag 'ORA\$OEM_LEVEL_0' database;
release channel oem_disk_backup;
allocate channel oem_sbt_backup1 type 'SBT_TAPE' format '%U' parms 'ENV=(NSR_DATA_VOLUME_POOL=oraclebackup1,NSR_DATA_VOLUME_POOL1=oraclebackup2,NSR_CLIENT=gendev)';
backup recovery area;
}
allocate channel for maintenance device type 'SBT_TAPE' parms 'ENV=(NSR_DATA_VOLUME_POOL=oraclebackup1,NSR_DATA_VOLUME_POOL1=oraclebackup2,NSR_CLIENT=gendev)';
delete noprompt obsolete recovery window of 75 days device type 'SBT_TAPE';


The hostnames/IPs of the cluster are:
node 1: racdev1 (192.168.15.176, physical) vracdev1 (192.168.15.206, virtual)
node 2: racdev2 (192.168.15.181, physical) vracdev2 (192.168.15.210, virtual)

On the cluster there are two databases: gendev and sandbox. (So far we've been restricting the conversation to gendev, but be aware that there is another database on the cluster.) Each database has one instance on racdev1 and one instance on racdev2. Neither the databases nor the individual instances have their own dedicated IPs. This is the standard setup for RAC databases running on Oralce clusterware.

Backups of each database are kicked off as an rman script run from Oracle Grid Control, which can run on either instance of the database. They are the standard Oracle-recommended scripts generated by grid control. The Networker parameters are passed using the parms syntax on the allocate channel commands in the script.

What should the value of NSR_CLIENT be for the backups for each of the two databases? If it's anything other than racdev1, vracdev1, racdev2, or vracdev2, I'm told it needs to have an IP, so what do we need to add to DNS?
 
dont use the instance name of your database (gendev) as the nsr_client
name. Instead use the physical node name for the nsr_client attribute.
The selection of the database instance is made with by rman with the connect target command.
There is the possibility that rman mixes up backups to sbt_tape and via snapshot to the flash recovery area.
If you want to use a incremental backup only backup the archivelogs.
If you want a full backup to tape use

"backup all (database)...;" instead of "backup backupset all not backed up since time 'SYSDATE-1';"
in your rman script.
 
I wasnt using any value at all for NSR_CLIENT and each node was backing up to its own node. But that causes the node to only know about its own backups. Right now lets say 10 days node1 backups then the next 10 days node to backups. Well node1 will only know about the 10 backups it did and node2 the same. We want to be able to have node1 and node2 see all the backups from both nodes. In order to do that emc is stating that we need to use a nsr_client that both nodes have access to, such as the database, but to do that the database base needs to be accessable by dns. Since this is a rac system, it is throwing me off, I am use to 2 pysical nodes and 1 virtual. This would be easy since I would just use the virtual as the common place. But since this is a 2 pysical and 2 virtual, I cant use those 2 virtuals.

So the main concern we are trying to answer is, how do we get it that both nodes can see each others backups, so when we crosscheck from say node1 we dont have wholes in the dates?

Thanks
 
the Information about the rman backups of the last 30 days are stored in the control-files of the instance.
With rac all nodes "know" about these backups.
I would advise you to backup from networker with an rman script. Doing so you can backup every time using the same physical host. This makes it easier to "find" a backup for recover.
But ist possible to recover from one client to another therefore you need a unique NSR_Client attribute for each rac node
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top