This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C3E96D.77AC8D50
Content-Type: text/plain;
charset="iso-8859-1"
All,
We are consistently getting RMAN/Netbackup status 5's on restores for a
particular Oracle Instance on a particular host. This restore works
succssfully on another host. Server/Client is NBU4.5 FP3 [Patch 5] on
Solaris 8. The restore fails at random points normally after about 3/4 hrs
into the restore with various sizes of data recovered All > 100GB. We have
verbose BPTM logging on + the usual dbext logs ETC ETC setup. Incidentaly
the following error appears to occur just prior the restore failing:
09:30:59.100 [8433] <2> mpx_read_data: waited for empty buffer 122 times,
delayed 26303 times
09:30:59.100 [8433] <2> send_brm_msg: MEDIA NOT READY
09:30:59.100 [8433] <2> io_close: closing
/usr/openv/netbackup/db/media/tpreq/NBY059, from mpxrestore.c.2482
09:30:59.104 [8433] <2> mpx_waiting_term: waiting for TERMINATE or another
START RESTORE
09:30:59.610 [8433] <2> read_brm_msg: TERMINATE
09:30:59.626 [8433] <4> mpx_read_backup: successfully restored 0 of 1
requests, read total of 76800 Kbytes at 79.921 Kbytes/sec
09:30:59.629 [8433] <2> read_backup_unmount_delay: waiting 180 seconds
before unmounting media after restore
09:31:17.222 [6362] <2> write_bytes: [6356] writing 1073741824 data bytes,
input length was 1073741824, SAVE_BYTES = 0, file = /nvfbl057_1_1
09:31:42.269 [6356] <2> read_brm_msg: STOP RESTORE indprd_1074201518
This is the point where our RMAN restores keep failing.
Sun/Veritas have so far drawn a blank on this. Could it be HBA or switch
releated. The h/w is a V480R [NB Server] 2GB HBA, to 2GB x 16 switch into 6
X LTO-II FC drives in a L180.
Backups are fine. We have never had an issue with these. Also timeout values
are set to 3600 on both the client and server.
Also, [Which may be related] Sun have mentioned that our TCP retransmission
rates are high from the server. Could this be a pointer in the right
direction?
Any help is really appreciated - This is driving us round the bend!
----------------------------------------------------
Kev Smith
Unix Systems Administrator.
Operational Support, IND Croydon.
E-Mail: kevin.m.smith AT siemens DOT com
Tel: 020 8760 4849
Mob: 07808 828595
----------------------------------------------------
Siemens Business Services Ltd
This e-mail contains confidential information and is for the
exclusive use of the addressee/s. If you are not the addressee, then any
distribution, copying or use of this e-mail is prohibited. If received in
error, please advise the sender and delete it immediately. We accept no
liability for any loss or damage suffered by any person arising from use of
this e-mail.
Siemens Business Services
Registered No: 1203466 England
Registered Office: Siemens House, Olbury, Bracknell, Berkshire, RG12 8FZ
------_=_NextPart_001_01C3E96D.77AC8D50
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.45">
<TITLE>RMAN Status 5 - Restores failing </TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2 FACE=3D"Microsoft Sans Serif">All,</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Microsoft Sans Serif">We are consistently =
getting RMAN/Netbackup status 5's on restores for a particular Oracle =
Instance on a particular host. This restore works succssfully on =
another host. Server/Client is NBU4.5 FP3 [Patch 5] on Solaris 8. The =
restore fails at random points normally after about 3/4 hrs into the =
restore with various sizes of data recovered All > 100GB. We have =
verbose BPTM logging on + the usual dbext logs ETC ETC setup. =
Incidentaly the following error appears to occur just prior the restore =
failing:</FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Courier New">09:30:59.100 [8433] <2><B> =
mpx_read_data: waited for empty buffer 122 times, delayed 26303 =
times</B></FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">09:30:59.100 [8433] <2> =
send_brm_msg: MEDIA NOT READY</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">09:30:59.100 [8433] <2> =
io_close: closing /usr/openv/netbackup/db/media/tpreq/NBY059, from =
mpxrestore.c.2482</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">09:30:59.104 [8433] <2> =
mpx_waiting_term: waiting for TERMINATE or another START RESTORE</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">09:30:59.610 [8433] <2> =
read_brm_msg: TERMINATE</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">09:30:59.626 [8433] <4> =
mpx_read_backup: successfully restored 0 of 1 requests, read total of =
76800 Kbytes at 79.921 Kbytes/sec</FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Courier New">09:30:59.629 [8433] <2> =
read_backup_unmount_delay: waiting 180 seconds before unmounting media =
after restore</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">09:31:17.222 [6362] <2> =
write_bytes: [6356] writing 1073741824 data bytes, input length was =
1073741824, SAVE_BYTES =3D 0, file =3D /nvfbl057_1_1</FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Courier New">09:31:42.269 [6356] <2> =
read_brm_msg: STOP RESTORE indprd_1074201518</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">This is the point where our =
RMAN restores keep failing.</FONT>=20
</P>
<P><FONT SIZE=3D2 FACE=3D"Microsoft Sans Serif">Sun/Veritas have so far =
drawn a blank on this. Could it be HBA or switch releated. The h/w is a =
V480R [NB Server] 2GB HBA, to 2GB x 16 switch into 6 X LTO-II FC drives =
in a L180.</FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Microsoft Sans Serif">Backups are fine. We =
have never had an issue with these. Also timeout values are set to 3600 =
on both the client and server. </FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Microsoft Sans Serif">Also, [Which may be =
related] Sun have mentioned that our TCP retransmission rates are high =
from the server. Could this be a pointer in the right =
direction?</FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Microsoft Sans Serif">Any help is really =
appreciated - This is driving us round the bend!</FONT>
</P>
<P><B><FONT SIZE=3D1 FACE=3D"Verdana"> =
----------------------------------------------------</FONT></B>
<UL>
<P><B><FONT SIZE=3D1 FACE=3D"Verdana">Kev Smith</FONT></B>
<BR><B><FONT SIZE=3D1 FACE=3D"Verdana">Unix Systems Administrator. =
</FONT></B>
<BR><B><FONT SIZE=3D1 FACE=3D"Verdana">Operational Support, IND =
Croydon.</FONT></B>
</P>
<P><B><FONT COLOR=3D"#0000FF" SIZE=3D1 FACE=3D"Verdana">E-Mail: =
kevin.m.smith AT siemens DOT com</FONT></B>
<BR><B><FONT COLOR=3D"#0000FF" SIZE=3D1 =
FACE=3D"Verdana">Tel: 020 8760 4849</FONT></B>
<BR><B><FONT COLOR=3D"#0000FF" SIZE=3D1 FACE=3D"Verdana">Mob: =
07808 828595</FONT></B>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Verdana">----------------------------------------------------</F=
ONT></B>
</P>
</UL>
<P><U><B><FONT SIZE=3D2 FACE=3D"Verdana">Siemens Business Services Ltd =
</FONT></B></U>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Verdana">This e-mail contains confidential =
information and is for the exclusive use of the addressee/s. If you are =
not the addressee, then any distribution, copying or use of this e-mail =
is prohibited. If received in error, please advise the sender and =
delete it immediately. We accept no liability for any loss or damage =
suffered by any person arising from use of this e-mail.</FONT></P>
</UL>
<P><FONT SIZE=3D1 FACE=3D"Verdana">Siemens Business Services</FONT>
<BR><FONT SIZE=3D1 FACE=3D"Verdana">Registered No: 1203466 =
England</FONT>
<BR><FONT SIZE=3D1 FACE=3D"Verdana">Registered Office: Siemens House, =
Olbury, Bracknell, Berkshire, RG12 8FZ</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C3E96D.77AC8D50--
|
