Re: ORA-12571: TNS:packet writer failure

spamdump_at_nospam.noway.nohow (Ed Stevens) wrote in message news:<3dd5225c.59202789_at_ausnews.austin.ibm.com>...
> On Fri, 15 Nov 2002 15:37:40 -0000, "Niall Litchfield"
> <n-litchfield_at_audit-commission.gov.uk> wrote:
>
> >"Ed Stevens" <spamdump_at_nospam.noway.nohow> wrote in message
> >news:3dd4f73d.48162894_at_ausnews.austin.ibm.com...
> >
> >> 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
> >
> >Obviously the usual advice to look at the generated trace file applies. IIRC
> >correctly you normally get the ORA-02063: preceding line from LN_NMMPDB when
> >the app is doing a select over a DBlink. If this does turn out to be the
> >case you could see if you get the same or similar errors thru sqlplus run
> >from the server console when you try to connect to the remote database.
> >
> >I'd agree with others though that it will probably turn out to be network
> >hardware/configuration.
> >
> >
> >--
> >Niall Litchfield
> >Oracle DBA
> >Audit Commission UK
> >*****************************************
> >Please include version and platform
> >and SQL where applicable
> >It makes life easier and increases the
> >likelihood of a good answer
> >
> >******************************************
> >
> >
> Ah, DBLinks . . . I'll take a look. I hope that doesn't lead where I fear it
> might. One of our DBLinks is to the Oracle Transparent Gateway ("Translucent"
> would be more accurate!). And Oracle won't even talk to us about that until we
> get these 8.0.5 databases to 8.1.x

Hmm, maybe there is an environment issue with one of your obscure dblinks. That is, under some conditions $ORACLE_HOME is not set right on the "other" side.

Expire time set in sqlnet.ora?

Do you have multiple gateways? Maybe one is misconfigured.

Check that the number of connections on both sides (ie, netstat -a|grep ESTAB|wc -l) has the appropriate kernel configurations. See note 68105.1 on metalink for some common kernel errors.

Are your dblinks the same version? I've seen bizarrity, especially stuff like 8 on Solaris to 7 on HP.

jg

--
@home.com is bogus.
And the most useless: oerr ora 12571