################
Filename…: sqlnet.ora
Date…: 1-MAY-14 08:33:29
################
AUTOMATIC_IPC = OFF
#TRACE_DIRECTORY_CLIENT =/logs/oracle/sqlnet
#LOG_DIRECTORY_CLIENT = /logs/oracle/sqlnet
NAMES.DEFAULT_DOMAIN = xxxx.com
ADR_BASE = /logs/oracle
NAMES.DIRECTORY_PATH=(TNSNAMES,EZCONNECT)
LOG_DIRECTORY_CLIENT=c:\oracle\ora-11.02.00.04\Network\Log
LOG_FILE_CLIENT=sqlnet_log
SQLNET.EXPIRE_TIME=0
TRACE_DIRECTORY_CLIENT=c:\oracle\ora-11.02.00.04\Network\Trace
TRACE_FILE_CLIENT=sqlnet_trc
TRACE_FILELEN_CLIENT=100
TRACE_FILENO_CLIENT=3
TRACE_LEVEL_CLIENT=OFF
TRACE_TIMESTAMP_CLIENT=ON
TRACE_UNIQUE_CLIENT=ON
USE_DEDICATED_SERVER=OFF
OK, so I guess c:\oracle\ora-11.02.00.04\Network\Log and c:\oracle\ora-11.02.00.04\Network\Trace are the folders you were talking about that you don’t have write permission on?
I tried putting those settings in my sqlnet.ora, pointed those params to real folders which I then made read-only. Somehow Oracle managed to write a sqlnet_log.log file in the log folder anyway when I tried to make a connection with a bad password (which failed quickly). So I’m not sure that my test was valid. I don’t suppose you can make a change on your end temporarily remove the LOG_* settings and see what happens like that?
This seems like it’s a good lead though.
I just went through several iterations of custom Sqlnet.ora settings pointing to log directories that are known to be writable. I also tried having those log_* settings commented out. In all cases, the slow response persists.
Maybe we are barking up the wrong tree. 
Evening all,
Could it possibly be that the tnsnames.ora entry has a couple of addresses and the first isn’t available? Think primary and standby with primary address first, standby second. But the current primary is the second address - so there’s a delay while the connection to the first address times out?
What response does tnsping database_alias give, it shouldn’t take long, a few milliseconds at best. That’s just testing the listener response obviously.
Does the listener log, or database alert log show any connection problems?
Are there any database login triggers doing any ‘interesting’ login checks?
Are you logging in as sysdba, or attempting to do so, and audit_sys_actions is true, and the logging is remote? Or just plain slow.
Is it RAC and does the connection get sent to a different service on a remote node?
Turn on tracing and check the log files.
HTH
Cheers,
Norm. [TeamT]
First of all, I’ve just installed oracle client 18 and I tried like that but It’s waiting again. Then I checked the parameter of “audit_sys_operations” was false and I set it as “true”. However, nothing has changed, we are waiting around 45 sec for each wrong logins.
By the way, I have no trigger in database.
In my opinion, this situation is not related with tnsnames.ora because when I try to connect with a direct connection, again I am waiting too much time .
Hmm. What happens when you use SQL*Plus to make the connection with the
wrong details? Is it as slow as Toad, or quicker?
I’ve just tried with SQL*PLUS, Oracle SQL Developer and PLSQL Developer by using same client and I got instant response under 1 sec in those tools.
This is sounding more and more like it’s on Toad’s side… The only thing I can think of is that there is some slowness with Toad reading/writing your saved PW to disk when it’s no longer correct. If you don’t mind, a quick test could possibly rule this in/out. Close Toad, go to your app data folder, Toad’s user files, and rename “connections.xml”. Launch Toad and try to make this connection again from scratch.
what about other oracle errors - do they come up quickly or slowly?
2 kinds that I can think of here - other “you can’t connect” type errors (such as account locked or DB in restricted session), or “already connected and still connected” type errors (such as table/view does not exist).
Hey @mrpilotron or @dbarocco or anyone else who can reproduce this problem - if you’re willing, contact me by email john.dorlon@quest.com. I’d like to send you a small test program or two to try to narrow this thing down. Test program would just connect to DB and not do anything else.
Thanks.
Unfortunately, our company IA policies prohibit downloading any sort of executable files to our PC without it going through the network admin first. I will check with them and see what can be done.
I just tested the “account locked” error message and it returned instantly regardless if I used the correct password or not.
I also tested unchecking the “Save passwords” check box and it made no difference.
That’s interesting about account lock not being slow too.
We’ve just solved the problem by copying following .xml file to the following path indicated below.
XML FILE : http://community-downloads.quest.com/toadsoft/ORACLE/VERSION/online_resources.xml
PATH: C:\Users\AppData\Roaming\Quest Software\Toad for Oracle\13.0\User Files
After the copy process you have to restart TOAD.
At first wrong password attempt, TOAD waits for a while. Then you’ll get a quick response for the wrong password attempts.
prior to downloading that file, did you have a different version of it, or was it not there at all? If prior version, can you send me the old one? john.dorlon@quest.com. thanks.
You may use this xml file for all other versions. We tried for Toad 12.0 and 13. 0 all compatible