Re: Shared Server Configuration: When exactly is the connect to the dispatcher established?

Christian Hartmann wrote:

> "Howard J. Rogers" <hjr_at_dizwell.com> wrote in message
> news:<4134e5ee$0$2569$afc38c87_at_news.optusnet.com.au>...
>
>> So, yes: the connection to a dispatcher is made when you say 'connect
>> scott/tiger' and remains connected until you type 'exit'.
>
> Thank you very much, Howard.
>
> The intention for my request is that I wonder if the described
> configuration at
>
>

http://download-west.oracle.com/docs/cd/B10501_01/network.920/a96580/advcfg.htm#475650
>
> for setting up a connection load balancing within a Oracle RAC
> environment based on a shared-server means, that an established
> connection from a client to a dispatcher is ALWAYS pointed (and NEVER
> CHANGED) to exactly the node to which the connection has been
> established?

I didn't quite understand that sentence!

Forget RAC for a moment. Load-balancing in a shared server environment simply means that the listener is aware of the number of users connected to each dispatcher (and the dispatchers re-register with the listener every few minutes to keep that information up-to-date). As a new connection request is received, the listener works out which dispatcher has the fewest number of connections and routes the new user through to that one.

With RAC, there is another level of load-balancing possible, because PMON re-registers itself with listeners every few minutes and reports the number of connections to each instance AND the CPU load of the machine it's running on. On receiving a new connection request, the listener handling the call routes the user through to whichever node has the smallest CPU load.

Put the two together.
Node A, 200 users, 60% CPU, 2 dispatchers, 103 users on D1 and 97 on D2. Node B, 400 users, 40% CPU, 3 dispatchers, 150 on D1, 160 on D2, 90 on D3

I make a new connection request, and contact the listener on, say, Node A (which listener I contact actually makes no difference to what happens). That listener will route my connection through to Node B, because that has the least CPU load. And it will route it through to Dispatcher 3 on that node, because that has the fewest number of users of all available dispatchers.

So I hope that was what you were after. All that is needed to make it happen is for each instance to know how to find, and register with, ALL instances. That will require LOCAL_LISTENER and REMOTE_LISTENER parameters to be configured appropriately. Otherwise, it all just happens.

Regards
HJR
>
> Any opions about this?
>
> Regards,
>
> Christian
Received on Wed Sep 01 2004 - 06:07:10 CDT