RE: long logon times through sqlnet

From: Mark W. Farnham <>
Date: Mon, 30 Mar 2009 11:58:18 -0400
Message-ID: <>

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



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: [] On Behalf Of Dba DBA
Sent: Monday, March 30, 2009 11:38 AM
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?

Received on Mon Mar 30 2009 - 10:58:18 CDT

Original text of this message