Re: DNS and SQL*Net Issue
- From: mkb <mkb125@xxxxxxxxx>
- To: "Bobak, Mark" <Mark.Bobak@xxxxxxxxxxxx>, "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 22 Jan 2010 13:58:50 -0800 (PST)
Mark,
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@xxxxxxxxxxxx>
To: "mkb125@xxxxxxxxx" <mkb125@xxxxxxxxx>; "oracle-l@xxxxxxxxxxxxx"
<oracle-l@xxxxxxxxxxxxx>
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of mkb
Sent: Friday, January 22, 2010 3:17 PM
To: oracle-l@xxxxxxxxxxxxx
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
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
