RE: long logon times through sqlnet

whois hostname from a client that has unix utilties (DNS working at
reasonable speed?)

 

and 

 

tnsping

 

seem like good candidates as quick shots before you start tracing in detail.

 

Having automated clients at typical important client locations if increasing
network distance to your servers is a useful early warning problem detection
and diagnosis utility if your system is worth monitoring for service levels.
Testing the non-Oracle specific network substrate is a useful way to know
where to look next.

 

good luck. Network stuff has so many self-healing layers (good thing) that
it can obscure (bad thing) transient hardware problems or weird speed
renegotiations. If the configuration is "hey, we fixed it transparently,
don't log that we had to do something" you won't see an error. Tracing
enough to be useful can compete with normal throughput on a busy network. So
relatively light service level monitors (I don't tell you what is wrong, I
just tell you whether it is within spec) can really help.

 

  _____  

From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Dba DBA
Sent: Monday, March 30, 2009 11:38 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: long logon times through sqlnet

 

Oracle 10.1.latest patch

OS: Tru 64

 

oracle does not have 10.2 for tru 64. 

 

This just started to happen. We have not changed anything. If we login from
the command line on the server and bypass sqlnet logon time is normal. If we
go through the listener logon time is 30 seconds. We are not out of memory
or at any resource limits. We have a ticket with Oracle but they are
pointing all over the place.

 

for some reason they have not asked for a sqlnet trace. I just got one and I
don't see anything in it so I am sending it to support. I ran an AWR report
and do not see any waits outside the norm. This tells me that the issue is
happening before you get to the database. so it is a listener issue.

 

is there any other type of trace I should run? OS level? Or log file to look
at to help diagnose this?

Other related posts: