Oracle RAC Administration - Part 15: Connection Load Balancing and FAN
February 15, 2007
In our last article, we looked at the service architecture. We will continue our quest to understand the workload characteristics and the load balancing connections in our Virtualized RAC.
Introduction to Workload Management
Connection Load Balancing
With Oracle Notification Services (ONS), we are able to have our RAC balance our client connections across the nodes. The CLB (connection load balancing) can be handled on the server-side or on the client-side. The client-side takes care of the connection sharing across the Listeners, while server-side load balancing manages and handles the connection requests to the most willingly available node whose information is in turn provided to it by the LBA (Load Balancing Advisory).
This in turn is analyzing the goals that may have been set for the LBA. You can use a long goal or a short goal for this connection load balancing. Lets take a look at them both quickly.
Long Goals: Use long goals for applications that need long
uninterrupted connections. It is the default connection load balancing goal. To
see how to implement them, lets take a simple syntax. Using the
EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'FOKESERV' , clb_goal => DBMS_SERVICE.CLB_GOAL_LONG);
Short Goals: Think of quick and fast transactions like ordering or placing a secure purchase like that on Amazon or any other place. You would prefer to fill the order up fast and if, for any reason the process is delayed, the connection is restarted, ensuring that the transaction is performed in a short-lived connection. Checking the syntax, here CARTSERV is the service in question:
EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'CARTSERV' , CLB_GOAL => DBMS_SERVICE.CLB_GOAL_SHORT);
Note: When you install your RAC with the DBCA (Database Configuration
Assistant), server-side load balancing is enabled by default. Also check out
the sample script in
The ONS maintains client connections until the client decides to close the connection or if a node fails or any other form of outage prevents the continuity of that connection. However, if you configure TAF (transparent application failover) then the connections are moved to another healthy instance. For a typical SARG (Select Arguments), TAF can restart the query. Alternately, from the client side, if you were accessing information on the web, the search would simply carry on without you noticing the failover of the connection to another node. However, if you were in the middle of a transaction (INSERT, UPDATE, or DELETE) then the application must rollback the failed transaction and submit it again. Any other session's customizations must be re-executed. However, in a normal processing scenario the sessions dont move irrespective of the workload changes, newer sessions are just redirected to other nodes.
With the services, the deployment of TAF only becomes easier. By defining a TAF policy for a service, all connections using this service will have TAF automatically enabled for them. No client-side intervention is required, meaning the server-side TAF setting will override the TAF setting at the client level. In order to define the TAF policy you will need the DBMS_SERVICE procedure:
EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'fokeserv.domain.com' , aq_ha_notifications => TRUE , failover_method => DBMS_SERVICE.FAILOVER_METHOD_BASIC , failover_type => DBMS_SERVICE.FAILOVER_TYPE_SELECT , failover_retries => 180 , failover_delay => 5 , clb_goal => DBMS_SERVICE.CLB_GOAL_LONG);
Client-side load balancing is defined in your client
connection with the parameter
FAN (Fast Application Notification)
As the Oracle RAC manual states:
RAC publishes the FAN events the minute any changes are made to the cluster. So, instead of waiting for the application to check on individual nodes to detect an anomaly, the applications are notified by FAN events and are able to react immediately.
FAN also publishes load balancing advisory (LBA) events. Applications are in a position to take full advantage of the LBA FAN events to facilitate a smooth transition of connections to healthier nodes in a cluster. One can take advantage of FAN is the following ways:
For instance, a typical
In this article, we looked at the CLB and FAN. In future articles, we will continue to discuss the services architecture and discuss FAN in detail and take a look at the LBA.