Cluster Managed Services

With Oracle RAC 10g, Oracle introduced Cluster Managed Services. This allows a dba to manage the workload running in their Oracle RAC database. Within the database, there are several attributes to a service which allow you to define performance characteristics for the workload. In an Oracle RAC environment, you can manage where the service runs by managing the parameters stored in the Oracle Clusterware resource. You can also monitor performance by service.

Many features of the Oracle Database are integrated with services. Oracle Streams, creates a service for each queue. This allows the queue to be accessed by the application independent of which instance the capture and apply processes are running. These services are created automatically by the database when you create the queue and should not be manaually dropped (or your queue may not work any more). The Database will clean up the service when you delete the queue. Oracle Scheduler can automatically assign a job class depending on the service used. Users connected to a service can automatically be mapped to a resource manager group. Oracle XMLDB will create its own services. These services are managed by the database and can not be stopped/started by the dba like user created services. A simple rule of thumb you can use, is if you did not explicitly create the service, you cannot manage the service.

The attributes for a service in the database include name, goal, clb_goal, and TAF policy. The goal is used to take advantage of the load balancing advisory. In an Oracle RAC database, we keep track of the work in the cluster for a given service. Based on the current workload in the cluster, Oracle RAC recommends how to distribute incoming connections across the active instances providing a given service. Clients who listen to the load balancing advisory can then allocate work across the cluster based on the current workload. Clients integrated with the load balancing advisory are Oracle JDBC Implicit Connection Cache, Oracle ODP.Net Connection Pool, Oracle OCI Session Pool, Oracle Connection Manager, and Oracle Listener. The clb_goal is the connection load balancing goal which tells the listener what type of connections it is dealing with. Short is for applications using the load balancing advisory (IE an Oracle Connection Pool) or applications that connect to the database for short sessions. Long is for applications that connect to the database for long periods (such as Oracle Forms applications) or when using connection pools that are not integrated with the load balancing advisory. The addition of the TAF policy to the service makes it much easier to administer TAF. All users connecting with the service will automatically get the TAF policy, you do not have to edit the client connection string. The Service TAF policy will override the client TAF policy. You must use DBMS_SERVICE pl/sql package to edit these attributes. For goal and clb_goal, the EM DBControl cluster managed services page will use PL/SQL under the covers to edit these attributes.

If your application is using XA transactions, there is a special attribute on the service in the database. This is a DTP service (DTP for distributed transaction processing). When using XA transactions with Oracle RAC 10g, you must direct all branches of the global transaction to a single instance in the cluster. Oracle RAC will ensure a DTP service is only active on one instance and when the service fails over, we will ensure that the first level of recovery has completed before activating the service on another instance. This type of service is sometimes referred to as singleton. This attribute is set with the DBMS_SERVICE package or using the EM DBControl Cluster Managed Services Page.

If you are using Fast Connection Failover for OCI based clients (OCI and ODP.NET), you must set the AQ_HA_NOTIFICATIONS attribute for the service. This tells the database to publish the FAN HA events to the internal queue for OCI. This attribute is set with the DBMS_SERVICE package or using the EM DBControl Cluster Managed Services Page.

In a cluster, you can define a service to run on a subset of the Oracle RAC instances. A service has its preferred instances (instances where it should run during normal operations) and available instances (instances where it should run if a preferred instance fails). If a preferred instance fails, the service is moved to an available instance. The cluster will try to keep the service running on the same number of instances as defined in the preferred attribute. We refer to this as the cardinality of the service. If the service is running on an available instance, and the preferred instance is restarted, you will have to manually relocate the service back to the preferred instance. This can be automated through a server callout, see the OTN Sample Code Page for RAC for examples.

For more details on services and using the different attributes, see the whitepaper Automatic Workload Management with Oracle RAC 10g or Automatic Workload Management with Oracle RAC 11g available on OTN (otn.oracle.com/rac). Also read the Oracle Real Applciation Clusters Administration and Deployment Guide.