Re: Slow response when connecting via LISTENER vs. Bequeth - any ideas?

Thanks for the quick reply Sean. How does the dedicated server process then return the data back to the client, if the client is on the same machine?

If the client (ie. sqlplus) and server (oracle) are on the same unix machine, why does the network get involved after the connection has been established? Is it possible that all the data being returned, is actually leaving the machine and coming back over the NIC? We started to believe that this was possible on the clustered machine just due to the nature of Tru64 clustering; but then we tried the same thing on a non-clustered Tru64 machine, and had the same results - connecting using the @service_name after the password meant slow response. In fact, when the DB and client are on separate machines, response times are faster then when both are on the machine, but never as fast when the bequeth connection is used (no @service_name).

"Sean Fitzgerald" <sfitzgerald_at_centurytel.net> wrote in message news:Qghl7.5300$tE2.2102593_at_feed.centurytel.net...
> You need to look at your network. The listener only plays a small part in
> the client connection and only at the start. When a client connects for
the
> first time, the listener receives the request on port 1521 (default).
Next
> the listener spawns a dedicated server process for the client, and gives
the
> connection over to that process which establishes its own connection with
> the client. The listener is out of the picture after this happens.
>
> The slow part of the listener process (on UNIX) is creating the dedicated
> server process. Returning data from queries does not involve the
listener.
> In fact, if you terminate the listener process, all existing connections
are
> unaffected (only new connections will be prevented).
>
>
>
Received on Tue Sep 04 2001 - 23:19:10 CDT