Sunday, 15 February 2015

Load Balancing Advisory and Connection Load Balancing in RAC

Oracle Net Services provides the ability to balance client connections across the instances in an Oracle RAC configuration. There are two types of load balancing that you can implement:

Client-side load balancing. Client-side load balancing balances the connection requests across the listeners. Set via LOAD_BALANCE parameter in the the net service name within a TNSNAMES.ORA file, it is just a random selection of the addresses in the address_list section of the net service name.

Server-side load balancing .With server-side load balancing, the listener directs a connection request to the best instance currently providing the service. Set via REMOTE_LISTENER in SPFILE, each instance registers with the TNS listeners running on all nodes within the cluster. By default this load balance is done on the instance on node. This can be changed to session based if required.

From 10g release 2 the service can be setup to use load balancing advisory. This mean connections can be routed using SERVICE TIME and THROUGHPUT.  Connection load balancing  means the goal of a service can be changed, to reflect the type of connections using the service.


Configuring the Load Balancing Advisory 

GOAL

None(0):When set to 0(NONE), this disables the ONS notifications to the Client as to the load of the various nodes.

Service Time(1)Attempts to direct work requests to instances according to response time. So if one node takes longer to do the same work, the client can be informed of this load difference, so it can now
direct further work to the node that is taking less time.Load balancing advisory data is based on elapsed time for work done in the service plus available bandwidth to the service.

Example to modify a service called ORCL and setup the service  to use SERVICE_TIME

EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'ORCL'  
, goal => DBMS_SERVICE.GOAL_SERVICE_TIME -  
, clb_goal => DBMS_SERVICE.CLB_GOAL_SHORT);

Throughput(2):Attempts to direct work requests according to throughput. The load balancing advisory is based on the rate that work is completed in the service plus available bandwidth to the service. Instead of figuring out how long something takes, it is the frequency this work occurs that is used.
So if node one is able to handle 10  transactions, while node two can handle 12, in the same amount of time, then the client will be told to go to node two. So even if node two will take longer to handle a specific job, it can handle more jobs at one time then node.

EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'ORCL' -
        , goal => DBMS_SERVICE.GOAL_THROUGHPUT -
       , clb_goal => DBMS_SERVICE.CLB_GOAL_LONG);
You can see the goal settings for a service in the data dictionary and in the DBA_SERVICES, V$SERVICES, and V$ACTIVE_SERVICES views

Configuring Connection Load Balancing

CLB_GOAL.

Long(2). Use the LONG connection load balancing method for applications that have long-lived connections. This is typical for connection pools and SQL*Forms sessions. It does not matter if GOAL is set or not for this condition as the point behind this setting is to balance based on  number of sessions. LONG is the default connection load balancing goal.

Example to modify service ORCL and set CLB_GOAL long

EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'ORCL'
        , clb_goal => DBMS_SERVICE.CLB_GOAL_LONG);
Short(1).Use the SHORT connection load balancing method for applications that have short-lived connections. The database uses first the GOAL setting to have PMON tell the Listener
which node to prefer

Example to modify service ORCL and set CLB_GOAL short

EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'ORCL'
, CLB_GOAL => DBMS_SERVICE.CLB_GOAL_SHORT);

Please note for 11.2 onwards for DBMS_SERVICE.MODIFY_SERVICE >> This procedure is deprecated in databases managed by Oracle Clusterware and Oracle Restart with Release 11.2. While the procedure remains available in the package, Oracle recommends using srvctl to manage services. This is because the service attributes are stored in CRS by srvctl, and overwrite those specified by DBMS_SERVICE. The DBMS_SERVICE procedures do not update the CRS attributes.

No comments:

Post a Comment