RE: DNS and SQL*Net Issue

From: Bobak, Mark <>
Date: Fri, 22 Jan 2010 16:06:50 -0500
Message-ID: <>

Hi Mohammed,

This is Oracle's LDAP autodiscovery feature in action. SQL*Net library looks for an SRV record, that will tell it where to find your local LDAP server.

I'm not sure why it would do the autodiscovery if you explicitly set NAMES.DIRECTORY_PATH=(TNSNAMES,EZCONNECT). Seems that if LDAP is not set in NAMES.DIRECTORY_PATH, there's no need to autodiscover. Perhaps the code does the autodiscovery *before* checking the value of NAMES.DIRECTORY_PATH?

Secondly, why does this cause your connect to fail? Specifically, what error are you seeing when failure occurs?

Third, just had another thought. Do a 'tnsping your-connect-string' and look in the output for two lines that look like this: Used parameter files:

Look at which sqlnet.ora file is actually being used. Is that the one that you edited, that has your value of NAMES.DIRECTORY_PATH defined in it?

Hope that helps,


-----Original Message-----

From: [] On Behalf Of mkb Sent: Friday, January 22, 2010 3:17 PM
Subject: DNS and SQL*Net Issue

Hi Folks,

I've got a remote system running RHAS 4 64-bit and Oracle 64-bit.

When we put a valid value for a nameserver in resolv.conf, it seems that SQL*Net or something from the Oracle side tries resolving which has a negative impact on returning result sets to client i.e. they never get them.

Now, when we remove the nameserver value from resolv.conf, Oracle stops resolving and queries results are returned to clients in no time.

We're not running LDAP and I've set NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT) in the server sqlnet.ora. Anyone know what's going on or how to turn this behavior off when a valid entry exists in resolv.conf?

BTW, the remote system is a couple thousand miles away and I don't really have access to it except through a very grumpy SA.





-- Received on Fri Jan 22 2010 - 15:06:50 CST

Original text of this message