Re: 10g - Sqlnet and redundant oid servers
- From: Jared Still <jkstill@xxxxxxxxx>
- To: harel.safra@xxxxxxxxx
- Date: Thu, 6 May 2010 10:08:02 -0700
Just to follow up on this:
Just now I tested this on a couple of test boxes, and the TCP timeout did
not come into play. It didn't matter if the OID machine was up or down,
the name was resolved within a couple seconds when the secondary
servers was used.
It would seem there are some environmental factors involved in this, though
I don't yet know what they are.
We ran into some issues with OID in the past that appeared to be
environmental
in nature, though we don't know why the difference between lab and
production.
Something similar may be going on here.
Following are my notes on setting up OID Dynamic Discovery where we had the
issue.
===================
When setup in the lab, OID dynamic discovery worked well.
When enabled in production, it was very slow.
It was found via strace that a nanosleep() call of from 1-5 seconds was
being inserted into every lookup.
Oracle Support said that a random sleep was included when an error was
returned from DNS.
Sysadmin traced DNS and found that Oracle was requesting an LDAP Secure
record (LDAPS), which was not available on the DNS server.
Sysadmin created and LDAPS SRV record (port 636) in addition to the standard
one, and then we tried tnsping again.
With the LDAPS record in place, database name resolution became very fast.
Oracle Support ticket 7481403.992 has details on the issue.
========================
Support did not have an explanation for why the LDAPS record was being
requested.
Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist
Oracle Blog: http://jkstill.blogspot.com
Home Page: http://jaredstill.com
On Wed, May 5, 2010 at 10:12 AM, Jared Still <jkstill@xxxxxxxxx> wrote:
> On Wed, May 5, 2010 at 10:00 AM, Harel Safra <harel.safra@xxxxxxxxx>wrote:
>
>> That's because the "nothing listening on this port" is returned
>> immediately since the OS in the server is up and responsive.
>> OTOH, if the server were to be shut down you'd have to wait for the TCP
>> timeout.
>>
>>
> That has not been my experience.
>
> Server was up, OID was down, waits for TCP timeout ensued.
>
> My previous question still stands: Was the physical server up or down?
>
> Jared Still
> Certifiable Oracle DBA and Part Time Perl Evangelist
> Oracle Blog: http://jkstill.blogspot.com
> Home Page: http://jaredstill.com
>
>
>
Other related posts:
