Veritas-bu

[Veritas-bu] RMAN Not Using New Server

2006-12-27 16:13:10
Subject: [Veritas-bu] RMAN Not Using New Server
From: JMARTI05 at intersil.com (Martin, Jonathan (Contractor))
Date: Wed, 27 Dec 2006 16:13:10 -0500
Ok - so I've got the new Netbackup environment running and its backing
up Windows & Standard jobs just fine.  So I  migrate my first Oracle
Database.  Here's where it gets interesting...
 
The job fires on the new backup server (PBCOBK01) but only gets to
"connecting" in the activity monitor.  Looking at the logs on the local
machine I find...
 
from bphdb log...
 
15:50:29.763 [3740.3800] <4> bphdb do_script: INF - bphdb still working.
15:51:29.764 [3740.3800] <4> bphdb do_script: INF - bphdb still working.
15:52:29.766 [3740.3800] <4> bphdb do_script: INF - bphdb still working.
15:52:29.829 [3740.3800] <16> writeToSock: ERR - send() to server
failed: An existing connection was forcibly closed by the remote host. 
15:52:29.829 [3740.3800] <16> bphdb do_script: ERR - could not write
keepalive to the NAME socket
15:52:29.860 [3740.3800] <4> bphdb main: file C:\Program
Files\VERITAS\NetBackup\temp\obackup_class deleted.
15:52:29.860 [3740.3800] <16> bphdb main: ERR - Error code: 24
15:52:29.876 [3740.3800] <16> bphdb Exit: ERR - bphdb exit status = 24:
socket write failed
 
15:52:29.876 [3740.3800] <4> bphdb Exit: INF - EXIT STATUS 24: socket
write failed
 
from bpcd log...
 
15:42:19.091 [3216.4008] <16> bpcd main: Server access denied
15:42:19.122 [3280.3580] <2> bpcd main: offset to GMT 18000
15:42:19.122 [3280.3580] <2> bpcd main: Got socket for input 452
15:42:19.137 [3280.3580] <2> logconnections: BPCD ACCEPT FROM
132.158.203.21.684 TO 132.158.203.126.13782
15:42:19.137 [3280.3580] <2> bpcd main: setup_sockopts complete
15:42:19.169 [3280.3580] <2> ParseConfigExA: Unknown configuration
option on line 76: RenameIfExists = 0
15:42:19.169 [3280.3580] <2> bpcd peer_hostname: Connection from host
semibkup1 (132.158.203.21) port 684
15:42:19.169 [3280.3580] <2> ParseConfigExA: Unknown configuration
option on line 76: RenameIfExists = 0
15:42:19.169 [3280.3580] <2> bpcd valid_server: comparing pbcobk01 and
semibkup1
15:42:19.169 [3280.3580] <2> bpcd valid_server: comparing pbcobk02 and
semibkup1
15:42:19.169 [3280.3580] <2> bpcd valid_server: comparing pbcobk03 and
semibkup1
15:42:19.169 [3280.3580] <2> bpcd valid_server: comparing pbcobk01 and
semibkup1
15:42:19.169 [3280.3580] <2> bpcd valid_server: comparing pbcobk02 and
semibkup1
15:42:19.169 [3280.3580] <2> bpcd valid_server: comparing pbcobk03 and
semibkup1
15:42:19.169 [3280.3580] <16> bpcd valid_server: semibkup1 is not a
server
15:42:19.169 [3280.3580] <16> bpcd valid_server: semibkup1 is not a
media server
15:42:19.309 [3280.3580] <2> bpcd main: output socket port number = 531
15:42:19.309 [3280.3580] <2> bpcd peer_hostname: Connection from host
semibkup1 (132.158.203.21) port 684
15:42:19.309 [3280.3580] <2> bpcd main: Peer hostname is semibkup1
15:42:19.309 [3280.3580] <2> bpcd main: Got socket for output 716, lport
= 802
15:42:19.309 [3280.3580] <2> bpcd main: Connected on output socket
15:42:19.309 [3280.3580] <2> bpcd main: Duplicated socket on stderr
15:42:19.309 [3280.3580] <2> bpcd main: <---- NetBackup 5.1 0
------------initiated
15:42:19.309 [3280.3580] <2> bpcd exit_bpcd: exit status 46
----------->exiting
15:42:19.309 [3280.3580] <4> bpcd exit_bpcd: FTL - BPCD EXIT STATUS 46
 
semibkup1 is the name of my old backup server!?  Why is it looking
there?  I removed the old server entries from the client, restarted the
service, even reinstalled the client but it continues to look for
semibkup1 when starting the RMAN "child" jobs.  So the "parent" job
starts on pbcobk01 (new master) and the child job ends up on semibkup1
and the job eventually fails.  GREAT!  Windows NT Backups of this same
server run fine.  Any ideas?
 
Symantec support will get back to me in the next 8 hours... /sigh
 
Thanks,
 
-Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20061227/c66d021a/attachment.html