Optimize Distributed Workload - Expert Oracle RAC Performance Diagnostics and Tuning - page 501

(CONNECT_DATA=
(SERVER=DEDICATED)
(SERVICE_NAME=TAPS)
(FAILOVER_MODE=(TYPE=SELECT)
(METHOD=BASIC)
(RETRIES=20)
(DELAY=15))
)
)

When several users connect to the database, the listener in any of these nodes could be busy accepting requests
from some other user on the network, at which point the client machine is notified. When a callback is received, the
SQL*Net will attempt to make a connection to another IP address defined in the scan IP list. If this listener on this
node is also busy, another address in the list is attempted, and so on until a connection is established.
Client load balancing is not based on the availability of resources on the database servers but on the availability
of the listener to accept the users' connection request. To overcome this constraint, Oracle introduced another level of
load balancing called connection load balancing or server side load balancing.

Connection Load Balancing
Client load balancing is between the user session on the client machine and the listener and does not provide any
resource level load balancing. Client load balancing only distributed users across the various listeners picking an
address from the list available, when several users connected close to one another. If the clients connected at various
intervals, there was a potential that all users ended on the same node/instance. To help resolve this issue, Oracle
introduced server side or connection load balancing.
Under this method, connections are routed to different instances (least loaded) in the cluster based on load
information available to the listener. The PMON (Process Monitor) process on the respective nodes updates load
information to the listener. The frequency or update interval is based on the load on the respective nodes. For
example, if the load is very low, the update may take up to 10 minutes; on the other hand, on heavily loaded nodes,
updates may occur in as little as 1-minute intervals.
To implement this load-balancing feature, the parameters listed in Table 15-3 have to be defined.

Table 15-3. Instance Parameters

Parameter Description

LOCAL_LISTENER This parameter informs the instance regarding the local listener name defined for the node.

This parameter is only required to be defined if the listener on the local node is registered on a
non-default port (1521).

REMOTE_LISTENER

This parameter, when defined, informs the instance regarding all other listeners defined on
other nodes participating in the cluster.

The PMON will register with the listeners identified by the preceding two parameters defined in the server
parameter file. Once registered, the PMON will update the listener with profile statistics that allow the listener to route
incoming connections to the least loaded instance.
When an instance starts, the PMON registers itself with the listener. This could be verified by checking the listener log
file located at $ORACLE_BASE/diag/tnslsnr/<hostname>/listener/trace/ directory for the service_register string.