Re: Long connect time when one node in RAC goes down

I wrote a blog post on TNS listener configuration for RAC a while back that might help (if not this case, then maybe someone else stumbling upon this thread. The entry is at
http://www.dannorris.com/2008/07/21/tns-listener-configuration-for-oracle-rac/

Hope it helps. I think most of the points I covered in the post have already been addressed here. Perhaps most importantly, using only the VIP address in the listener's listening endpoints is something that is often misconfigured.

Dan

KRIUSHIN, Andrey wrote:
> Hi,
>
> An itermediate summary:
>
> 1. 6 seconds is a very strange number. It doesn't look like a TCP
> timeout (1-few minutes by default).
> I.e. if the client managed to issue SYN, and ip is not reachable,
> the client will wait for ACK few 60'ies seconds _*unless*_ the client
> have been set the (ASYNC) callback (through the timer, par ex) interrupt
> before falling into TCP stack
> I see one of Oracle's magic numer (3 seconds) times 2. Would like to
> see 200-300 lines of sqlnet.trc on the client before the error report.
> Actually that said, it leads to investigations at the client side.
>
> Might be intriguing if that functionality is included somehow into
> the _*native*_ Oracle's Oracle*Net
>
>
> Common practice of poor design of client's network access is
> a) we need (busyness rules require) the guaranteed responce in XXX [m]sec
> b) thus the client will setup its own timeout for the case, when the
> responce is not received in the specified timeframe
> c) typical goblin's action - forget about previous attempt (to
> establish the connection) and start a new one (nobody cares about socket
> used, server process started, listener forked ...)
>
> Usually leads to a kind of DoS attack from approved application. Ghmm
>
> d) another symptom of goblin's design - stateless connections, i.e.
> almost any request causes a new connection establishment & session
> creation overhead... Client connection pooling is too complex to understand
>
> 2. Mark have rised a good point (event if it not directly applicable to
> the this particular issue) - you should use only VIP's in any server
> tnsnames/listener.ora, i.e. never mix native node ip with VIP. Well,
> usually that seriously bothers when there are firewalls/ip remapping
> etc..., i.e. complex network organization. Anyway - I like the point.
>
> 3. I'd add to Ujang's comment - if EXTPROC is not used, drop it from
> the listener.ora
>
> 4. Did your answered Riyaj's request on the configuration files?
>
> -- Andrey
> PS. Sorry for emotions (goblins etc...)
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
>

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