Re: [Veritas-bu] RMAN restore to altnerate server failing

Thanks.

NB_ORA_CLIENT was set all along in the RMAN script. Initially NB_ORA_SRV was pointing to the old 6.5.4 master but that was fixed as soon as they told me they were having issues.

Prior to posting I had found that the No.Restrictions file was in db rather than db/altnames so had moved it (and even retouched) it but that didn’t help. (I didn’t see anything about needing to restart NetBackup on the master when I do this so didn’t restart.)

Also prior to posting I had found the bit about either having no CLIENT_NAME or using the one from the source host in the alternate server’s bp.conf in the 7.1 Oracle agent guide. The CLIENT_NAME was initially set to the alternate client so I commented it out but that didn’t help. I then changed it to the source client and it didn’t help either.

I had completely forgotten to check logs on the client. We have a dbclient log from yesterday that I am starting to parse through now as it does seem to have captured information. (In fact it is owned by the Oracle user that was attempting the restore.) There wasn’t a directory for bphdb so I’ve created that to allow for logging in future tests.

In dbclient log I did see from our last test yesterday:

17:15:41.235 [30917] <8> dbc_GetServerClientConfig: WARNING - NBU's client name= <spiderman> differs from gethostname()= <ironman.water.com>

However since that is labeled “WARNING” and the recommendiation is to use the source’s (spiderman in this case) CLIENT_NAME I’m assuming this can be ignored?

From: veritas-bu-bounces AT mailman.eng.auburn DOT edu [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Michael Graff Andersen
Sent: Thursday, May 19, 2011 1:12 AM
To: Lightner, Jeff
Cc: VERITAS-BU AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] RMAN restore to altnerate server failing

Hello Jeff

We always set the CLIENT_NAME in bp.conf and NB_ORA_CLIENT in the rman script to the source client when doing this on our AIX machines

On Windows you to set the NB_ORA_CLIENT as system environment variable for alternate restore to work

And you need to allow the alternate client to read the source clients backups in ..db/altnames. The touch file No.Restrictions is what we use

Also the bphdb and dbclient logs on the client sometimes gives indications of what the problem is

Hope this helps

Regards

Michael

2011/5/18 Lightner, Jeff <JLightner AT water DOT com>

We’re seeing the following when attempting a restore of an RMAN backup:

Starting restore at 18-MAY-11

channel ch00: looking for autobackup on day: 20110518

channel ch00: autobackup found: c-604673869-20110518-00

released channel: ch00

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of restore command at 05/18/2011 13:48:24

ORA-19870: error reading backup piece c-604673869-20110518-00

ORA-19507: failed to retrieve sequential file, handle="c-604673869-20110518-00", parms=""

ORA-27029: skgfrtrv: sbtrestore returned error

ORA-19511: Error received from media manager layer, error text:

Failed to process backup file <c-604673869-20110518-00>

On the NetBackup master itself I never see any sign that the restore was attempted. The above message is from the client from which the restore is being attempted. Also we’ve found that from that client we can’t list the backups but from the Production client from which they were originally backed up we can list them.

The client backed up and the atlternate one on which we’re attempting the restore are both RHEL5 and the master is RHEL6. All 3 are running NBU 7.1.

We had previously done this when the clients were 6.5.4 and the master was an HP-UX server running 6.5.4. We did not migrate to the new master but rather installed it from scratch then updated the clients to 7.1 and pointed them at the new master. We have had many successful backups of the first client since the move and update of clients.

Initially the DBA had not modified his script to use the new master but he is still having issues even though he has now done the modification.

I ran a tcpdump while he attempted a restore and saw that connections are being made from the alternate client to the master but nothing is ever going to the master’s logs nor is it ever actually creating a restore job in the Activity Monitor.

Has anyone seen this and if so how did you resolve it?

Is there something different about RMAN in 7.1 as compared to 6.5.4?

__________________________________________________________________________________________

Proud partner. Susan G. Komen for the Cure.

Please consider our environment before printing this e-mail or attachments.

----------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------

_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu