Re: DNS and SQL*Net Issue

Thanks for the quick response.

Unfortunately, I have very limited access to the resource.

I was at the site last week. We have a Java app that connects to the db using JDBC. I ran a 10046 trace and the database was returning result sets just fine. The problem was, the app at the other end wasn't able to render the page on the browser. Unfortunately, I didn't do any SQL*Net tracing (wish I had). It was only after I left did the SA run a wireshark session to find out what was going on. The connect does not fail, just that the client receives the result set after a very, very long time. There are no errors in the application error log (JDBC connect errors) and no errors on the server listener.log and sqlnet.log.

Anyway, cut a long story short, the way I installed and configured the system was without an entry in the resolv.conf as per my install instructions which worked fine. The way the SA did the re-install was with a valid DNS entry in resolv.conf which wound up affecting performance. I've never seen this behavior.

Thanks to your response, I was able to look up Metalink Doc 250675.1 which shed more light on this issue. Basically, the doc says that auto discovery mode cannot be turned off but can be influenced by setting some env vars such as ORA_LDAP_DNS i.e. overriding the value in resolv.conf.

Another strange thing about this issue is that if you put an invalid entry into resolv.conf the query results return just as fast as if there was no entry present. The slow down only presents itself when a valid entry is in resolv.conf. So setting ORA_LDAP_DNS to an invalid entry might work while still have a correct value in resolv.conf.

Thanks again for your help.

--

mohammed

• Original Message ---- From: "Bobak, Mark" <Mark.Bobak_at_proquest.com> To: "mkb125_at_yahoo.com" <mkb125_at_yahoo.com>; "oracle-l_at_freelists.org" <oracle-l_at_freelists.org> Sent: Fri, January 22, 2010 4:06:50 PM Subject: RE: DNS and SQL*Net Issue

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:
/oracle/product/11.2.0/db/network/admin/sqlnet.ora

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,

-Mark

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

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of mkb Sent: Friday, January 22, 2010 3:17 PM
To: oracle-l_at_freelists.org
Subject: DNS and SQL*Net Issue

Hi Folks,

I've got a remote system running RHAS 4 64-bit and Oracle 10.2.0.4 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 _ldaps._tcp_.oid.my_machine.com 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 _ldaps._tcp_.oid.my_machine.com 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.

Thanks

--

mohammed       

--

http://www.freelists.org/webpage/oracle-l       

--

http://www.freelists.org/webpage/oracle-l Received on Fri Jan 22 2010 - 15:58:50 CST