Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: ORA-12571: TNS:packet writer failure

Re: ORA-12571: TNS:packet writer failure

From: Ed Stevens <spamdump_at_nospam.noway.nohow>
Date: Fri, 15 Nov 2002 13:43:18 GMT
Message-ID: <3dd4f73d.48162894@ausnews.austin.ibm.com>


Comments embedded . . .

On Fri, 15 Nov 2002 09:46:12 +0200, Billy Verreynne <vslabs_at_onwe.co.za> wrote:

>Ed Stevens wrote:
>
>> Platform: Oracle SE 8.0.5.2 on NT4 Advanced server
>
>Always a good idea to run the latest 8.x Ed - there are many bugs fixed in
>8.1.7.4 patch set.
>

Absolutely agreed. All of our new stuff is coming up under 8.1.7.4 and we are in the process of upgrading the old stuff. Have completed all test databases and will be doing 4 servers of prod databases by the end of January.

>This could be just one of those weird and anoying bugs...One never knows.
>For example, from the 8.1.7.4 read me notes:
>Bug 1314755 ORA-12571 inserting a NULL-TERMINATED string into NVARCHAR2
>Bug 1690759 Spurious ORA-12571 possible using BEQUEATH connection if write
>is interrupted
>
>> Within the last couple of weeks we've gotten a rash of ORA-12571:
>> TNS:packet
>> writer failure. In the past these eventually were traced to faulty
>> network
>> equipment -- switches going south, a mis-configured router, etc. We've
>> been
>> clean for some time, then last week they started up again.
>
>How sure you are that the network hardware and network config are okay? My
>initial reaction would be something like "damn, we did not fix the network
>properly". :-)
>

Not at all sure. I'm not responsible for the network, and the guy that is is not particularly forthcoming. In the past, *I've* had to prove that *he* had a problem.

>> Something I find particularly interestng is that we have 6 db's on this
>> particular server, and only 2 of them are reporting this error.
>
>Are you getting this error on the server side? Or is the client app
>reporting it? If on the server.. I can not recall ever seeing this error in
>an alert or listener log...
>

First time for everything. Yes, it is on the server side. The messages are in the alert log:

Thu Nov 14 15:46:24 2002
Thread 1 advanced to log sequence 42730
  Current log# 4 seq# 42730 mem# 0: X:\ORAREDO\NPSP\LOG4A.RDO   Current log# 4 seq# 42730 mem# 1: Y:\ORAREDO\NPSP\LOG4B.RDO Thu Nov 14 15:52:51 2002
Errors in file e:\Oradmin\NPSP\udump\ORA00155.TRC: ORA-12571: TNS:packet writer failure
ORA-02063: preceding line from LN_NMMPDB

>If on the client side - the problem is likely then on the client. Are you
>not breaking an ethnernet cascade rule maybe from the client side? Through
>what routers and switches do this client go through? The usual network
>question stuff.
>
>> If it were a fundamental networking issue, I'd expect it to show on at
>> least all of the db's on this server and possibly db's on other servers
>> as well.
>
>Yeah, I agree somewhat with that. However that is not always the case. You
>need to be absolutely sure that this error does occur on the server and not
>on the client. Even with all the servers sitting on the same segment on the
>backend, not all IP configurations are equal. Maybe a missed DNS entry. A
>stuffup in the router table of one server. Unless you are 100% sure that
>you are comparing apples with apples, I would not think it a valid
>statement to say "if server A gives this error, so should server B".

Yes, there's always the chance of something being different between servers, if nothing else a physcial defect in the cabeling and/or patch panel between the server and the device where the server actually joins the network. But what I find harder to dismiss is that this is occurring on only 2 of the 6 databases on the *same* server.
>
>When troubleshooting problems, one of the two basic things I usually aim for
>is repeatability and isolation. These usually go hand in hand. If you can
>isolate and repeat the problem on a specific config/setup/manchine/
>connection, then you can easier trace and identify the problem.
>

Well, we have already pretty well isolated the problem to a specific db on a specific machine, but being able to replicate it at will is another matter.
>--
>Billy

--
Ed Stevens
(Opinions expressed do not necessarily represent those of my employer.)
Received on Fri Nov 15 2002 - 07:43:18 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US