This post is more than 5 years old

24 Posts

1361

January 30th, 2014 11:00

How can I create multiple clients from one existing client?

Hi,

  I have a host that exists in a high availability cluster.  This host has multiple data bases running on it.  The original RMAN module backup savegroups were configured to run with the physical server as the client ID (there are 4 data bases on the server).  One of the data bases failed over to another server in the cluster and the backups stopped working.  At this point, I'd like to use the virtual data base name as the client ID. This will allow the backup to run no matter which server in the cluster it is running on.  We have done this in the past and it works well.  For whatever reason, it was not set up this on this particular server.  I am trying to retrofit it.

  I was able to create the client with the virtual data base name as the Networker client.  I've added the -c VirtDBname to the tail end of the nsrdasv command in the backup command config section of the client, which should (I think) save everything in the indexes under the virtual DB Name (i.e. the new client name).  The backup runs successfully, but when I check the indexes the new client ID exists with nothing in it.  The actual data is being stored in the client ID of the old physical server. Note: I've verified that client IDs of the physical server and the virtual DB name are different.  Did I overlook anything?  It seems like Networker knows which indexes its used in the past and wants to continue to use them, even though the source data now exists on another physical client (while it ignores the new client ID of the virtual DB name).  Any ideas?

Thanks,

Jim

4 Operator

 • 

14.3K Posts

January 30th, 2014 11:00

For what you want you need:

a) create virtual client

b) put physical clients to remote access list of virtual client

c) update RMAN script to have NSR_CLIENT pointing to virtual name (as called in backup server)

d) if you have CFG files on non shared disk, make sure you have them at the same place on both physical servers

So, no -c thing here (you use this only for file system backup).

24 Posts

January 30th, 2014 13:00

Thanks for the reply.... I had the DBA update the RMAN scripts to change the NSR_CLIENT to the virtual name, I removed the -c option on the nsrdasv command (we have only done file system backups in a cluster, thus I thought that was a requirement,), added the remote access for the physical clients in the virtual client definition. Also the RMAN cfg files are on shared disks, thus the paths to the cfg files are the same.

I thought that would work... Alas, it gave me the same results.  The virtual client backed up the data on physical server B, saved the RMAN savesets in physical server A's index (where it originally existing before the fail over).  Note, physical server A was what NSR_CLIENT pointed to prior to the script change.

I did not delete and recreate the virtual client prior to this run.... I just removed -c option on the backup command and updated the remote access list.

Any additional thoughts?

Thanks,

Jim

24 Posts

January 30th, 2014 13:00

I double checked the script modified by the DBA and sure enough the RMAN script networker was pointing to wasn't the one the he updated.  Once that was straightened out we got the expected results.

Thanks for help!

4 Operator

 • 

14.3K Posts

January 30th, 2014 13:00

Hm, that would be strange.  OK, do following:

- have DBA run backup from DB host (rman cmdfile )... let's assume we are talking about archive logs so typical script would be:

connect rcvcat ;

connect target ;

run {

      allocate channel t1 type 'SBT_TAPE'

      parms 'ENV=(NSR_SERVER= , NSR_DATA_VOLUME_POOL= , NSR_CLIENT= )';

      allocate channel t2 type 'SBT_TAPE'

      parms 'ENV=(NSR_SERVER= , NSR_DATA_VOLUME_POOL= , NSR_CLIENT= )';

      backup filesperset 1 archivelog all format 'ORCL:/ARCHLOG_%d_%u/' delete input;

      release channel t1;

      release channel t2;

}

Once he runs this, check on backup server with mminfo and nsrinfo where did it go.  If this is ok, then we go back to backup server initiated part of the problem.

No Events found!

Top