Services and High Availability in Real Application Clusters

To enable the Enterprise grid vision, Oracle Database 10g introduces a powerful new automatic workload management facility called services. Services enable you to manage your application workloads as separate entities. You can control the processing resources that are allocated to each service and define how these resources will be automatically reallocated during failures or planned outages. You can also monitor the performance of each service and change the resources that are allocated to them. This enables you to ensure that service level agreements are maintained as business requirements change.

Services are a generic feature of the Oracle Database 10g; you can use services in both single-instance Oracle databases and in Real Application Cluster (RAC) deployments. In RAC deployments, however, the full power of services is realized because you can control the instances in your cluster that are allocated to different services at different times. This effectively ensures that business priorities are met by controlling how processing resources are applied to your application workloads.

Using Services in Real Application Clusters Environments

Services are groups or classifications of applications that comprise business components that extend and respond to application workloads. Examples of services are Accounts Payable (AP), Customer Relationship Management (CRM), and so on. Services in RAC enable continuous, uninterrupted database operations to support multiple services on more than one instance.

Services enable RAC to integrate cluster database resources into a single system image to optimize cluster manageability. This simplifies system deployment, testing, and disaster recovery and administrative overhead. With services, users connect to a database without regard for which instance executes the SQL application service.

You assign services to run on one or more instances, and alternate instances can serve as backup instances in case the primary instance fails. If a primary instance fails, then Oracle moves the service from the failed instance to a surviving alternate instance.

Services enable you to model and deploy both planned and unplanned operations for all types of high availability or disaster recovery scenarios. During outages, RAC automatically restarts key components. Components that are eligible for automatic restart include instances, Oracle Net Services listeners, and the database as well as several database subcomponents.

To respond to changes in your cluster database, RAC uses events for rapid notification of state changes. After failures, event notifications initiate recovery processing to eliminate network timeouts and to provide end-to-end recovery of critical applications.

Because key resources are linked by RAC high availability events, resources respond to these events regardless of where the events occur in your environment. You can also define events to extend notification to middle-tier applications to simplify monitoring.

You can also modify your cluster configuration and still maintain service availability due to the resiliency of client-to-database connections. This is because RAC continually propagates both service and cluster configuration information throughout your cluster database. With connect-time and run-time routing, the number of instances that offer a service is transparent to applications.

Adding and Modifying Services

Use the Database Configuration Assistant (DBCA) or Server Control (SRVCTL) to create services. Then, depending on the task you want to perform, use the DBCA or Enterprise Manager to administer them. You can measure resource usage at the service level and control services availability by setting performance thresholds.

When you create services in RAC, you can assign the services to instances for preferred (normal) and available (recovery) processing. You can identify other instances that are available to support the service if service levels change or for planned outages. Additionally, you can use the Oracle Resource Manager to create consumer groups that control the priority for the service. When a service's preferred instance becomes unavailable, Oracle re-connects users from the unavailable instance to an available instance.

If you use the Database Upgrade Assistant (DBUA) to upgrade a Primary/Secondary configuration from an earlier release of Oracle Database, then the DBUA will create one service and assign it to one instance as a preferred instance and to the other instance as an available instance.

Using the DBCA to Add and Modify Services

The DBCA Service Management feature enables you to manage service assignments and service preferences for instances and to configure Transparent Application Failover (TAF) policies. You can execute these procedures while your RAC database is running. Even if your instances or the RAC database is not running, you can still use the DBCA to configure services, but the services will not start. To add or modify services using the DBCA Services Management feature:

On the DBCA List of Databases page, select the cluster database for which you want to configure services and click Next. If the database that you selected already has services assigned to it, then the DBCA displays these on this page.

Click Add or Modify.

To add a service, enter the name of the service. Note that service names with the prefix SYS$ are reserved for use by Oracle internal processes. To modify a service, edit the service and configure the service's instance preferences and TAF policies. Assign the service to instances for preferred (normal) and available (recovery) processing. The DBCA records your changes when you select another service or proceed to another page.

Note:

Entries you make in the Add a Service dialog are appended to the SERVICE_NAMES parameter entry which has a 4KB limit. Therefore, the total length of the names of all services assigned to an instance cannot exceed 4KB.

To remove a service, select the service and click Remove.

Click Finish and the DBCA displays the Summary page. Click OK and the DBCA displays a progress dialog while it configures your services.

When you click Finish, the DBCA configures the Cluster Ready Services (CRS) resources for the services that you added, modified, or removed. The DBCA also configures the net service entries for these services and starts them. When you use the DBCA to remove services, the DBCA stops the service, removes the CRS resource for the service, and removes the net service entries.

Changing VIP Addresses

Use the following procedure to change a VIP address:

Stop all database and ASM instances.

Stop the listeners, and node applications using the srvctl stop nodeapps command.

Run the srvctl modify nodeapps command with the -A option as described in Appendix B.

Restart all of the instances and node applications that you stopped in Step 1 and 2.

Automatic Restarts after Failures

Some administrative tasks require that you prevent components from automatically re-starting. For example, to take a node and all of its instances and services offline for maintenance purposes, first disable the instance and its services using either Enterprise Manager or SRVCTL.

If a failure occurs and adversely affects a RAC database instance, then RAC moves any services on that instance to another available instance. Then CRS attempts to restart the failed software when the node comes back up.

Note:

If you stop an instance to perform administration, you must disable the instance with SRVCTL. Otherwise, if the node fails and then restarts, then CRS attempts to restart the instance during your administrative operation.

Administering Services with Enterprise Manager and SRVCTL

When you create a service with SRVCTL, you must start it with a separate SRVCTL command. However, you may later need to manually stop or restart the service. In addition, you may need to disable the service to prevent automatic restarts. You may also need to manually relocate the service or obtain status information about the service. Refer to the following sections for examples of how to start and stop services.

View the services that are available on the instances of a cluster database

View the lists of running, preferred, and available instances that were configured during service definition

View the TAF policy set for each service.

To access the Cluster Managed Database Services page, from the Enterprise Manager Home page, under View select Cluster Databases and click Go. This takes you to a cluster database's home page. Click the Administration tab and on the Cluster Database Administration page, under the High Availability options list in the right, click Cluster Managed Database Services.

The Cluster Managed Database Services page displays services that are available on cluster database instances. Also use this page to manually load balance services. On the Services Detail page, select the service that you want to administer using the radio buttons on the left-hand side of the panel and select an operation by clicking the command buttons on the right-hand side of the panel, such as ENABLE, DISABLE, and so on, and click OK. When you click OK, Enterprise Manager performs the operation that you selected on the service. Refer to the online help for more information about this page.

You can only administer a service with Enterprise Manager after creating the service with the DBCA or SRVCTL. In addition, to use TAF, you must have previously configured the service for TAF; you cannot use Enterprise Manager to create services or to set service TAF policies. To access the Services Details page:

To start or stop a service, access the service by way of the Cluster Database page Administration tab and click Start or Stop.

Enabling and Disabling Services with SRVCTL

By default, all services are enabled for automatic restart. However, for some administrative activities such as hardware repairs and planned upgrades, you must disable a service to prevent automatic restart. Use the following SRVCTL syntax from the command line to enable and disable services:

srvctl enable service -d db_name -s service_name_list [-i inst_name]

srvctl disable service -d db_name -s service_name_list [-i inst_name]

Relocating Services with SRVCTL

Use the following SRVCTL syntax from the command line to relocate a service, for example, from instance crm1 to instance crm3: