Oracle® Real Application Clusters Administrator's Guide 10g Release 1 (10.1) Part Number B10765-01 |
|
|
View PDF |
This chapter describes how to administer high availability features such as services within Oracle Real Application Clusters (RAC) databases. The topics in this chapter are:
Administering Services with Enterprise Manager and SRVCTL
See Also: Oracle Real Application Clusters Installation and Configuration Guide for information about installing and configuring RAC |
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 multiple instances.
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. Because the Oracle Resource Manager is integrated with RAC, services also improve the throughput for applications running in RAC environments.
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.
See Also: PL/SQL Packages and Types Reference for more information about theDBMS_SERVICE PL/SQL and DBMS_MONITOR packages and for more information about setting thresholds |
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 Welcome page, select the Oracle Real Application Clusters option and click Next.
On the DBCA Operations page, select Services Management and click Next.
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.
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.
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. |
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.
Administering Services in Real Application Clusters with Enterprise Manager
Administering Services in Real Application Clusters with SRVCTL
Use the Enterprise Manager service administration page to:
Enable, disable, start, stop, and relocate cluster database 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.
See Also:
|
The following sections explain how to use SRVCTL to administer services.
Enter the following SRVCTL syntax from the command line:
srvctl start service -d <name [-s <service_name_list>] [-i <inst_name>] [-o <start_options>] [-c <connect_str> | -q]
srvctl stop service -d <name -s <service_name_list> [-i <inst_name>] [-o <start_options>] [-c <connect_str> | -q]
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_name1,service_name2,...> [-i <inst_name1,inst_name2,...>]
srvctl disable service -d <db_name -s <service_name1,service_name2,...> [-i <inst_name1,inst_name2,...>]
Use the following SRVCTL syntax from the command line to relocate a service, for example, from instance crm1 to instance crm3:
srvctl relocate service -d crm -s crm -i crm1 -t crm3 srvctl status service -d crm -s crm -v
You can perform other administrative tasks with SRVCTL as described in Appendix B, "Server Control (SRVCTL) Reference".