2 Design and Deployment Techniques

Service Topologies and Managing Workloads in Real Application Clusters Environments

Services are the basis for workload management in RAC. Clients and mid-tier applications make connection requests by specifying a global service name. Because RAC can reallocate services among instances in response to planned and unplanned outages, services greatly extend the availability and scalability of RAC environments.

Recommended Real Application Clusters Service Configurations

The recommended service configuration is to uniformly distribute service assignments across all available nodes. This simplifies your configuration and provides optimal high availability. Another approach is to non-uniformly configure services. In other words, workload sharing configurations can resemble many different topologies.

For example, assume that you have a five-node cluster with two instances, A and B, serving as the preferred instances for CRM. This same cluster could have instances C, D, and E as the preferred instances for AP. Instances A and B are the available instances for AP if one or more of AP's preferred instances become unavailable. Instances C, D, and E are the available instances for CRM if one or more of the CRM preferred instances becomes unavailable.

This configuration enables each service to use a group of instances that acts as both the preferred instances and as the available recovery instances. After an outage, a client recovers its connections on another instance in the same group.

In this configuration, during normal operations RAC routes application sessions by service to separate groups of instances. If a preferred instance becomes unavailable, then CRS relocates connections among the remaining RAC instances that offer that service.

Workload managed configurations achieve the highest availability and performance by transparently maintaining affinity based on service. Planned and unplanned outages on one domain can be isolated from other domains and the affected service is recovered or upgraded in isolation.

Automatic Workload Repository

The Automatic Workload Repository tracks service level statistics as metrics. Server generated alerts can be placed on these metrics when they exceed or fall below certain thresholds. You can then respond, for example, by changing the priority of a job, stopping overloaded processes, or by modifying a service level requirement. This enables you to maintain continued service availability despite service level changes. You can configure service levels to have priorities relative to other services, and you can also configure:

• The measurement of service quality

• Event notification and alert mechanisms to monitor service quality changes

• Recovery scenarios for responses to service quality changes

The Automatic Workload Repository ensures that the CRS workload management framework and resource manager have persistent and global representations of performance data. This information helps Oracle schedule job classes by service and to assign priorities to consumer groups. If necessary, you can rebalance workloads manually with the DBMS_SERVICE.disconnect_session_by_service_name PL/SQL procedure. You can use this procedure to disconnect a series of sessions and leave the service running.

Setting Service Levels and Thresholds

Enterprise Manager and local listeners subscribe to events that indicate changes in service levels. You can set service level metric thresholds with either Enterprise Manager or with Oracle-supplied packages.

You can see historical values for metrics in the V$SERVICEMETRIC_HISTORY view. Information about a service from the application level is available in the V$SESSION and V$SQL views. Service levels, or thresholds, are the baseline operational levels, and events indicate violations of these baselines. You can also examine GV$SVCMETRIC for timings such as resource consumption. Use the V$ACTIVE_SERVICES and GV$ACTIVE_SERVICES views to identify which services are running on which instances.

How Cluster Ready Services Manages Service Relocation

When an instance goes offline due to a planned outage or failure CRS relocates the service to another available instances. CRS relocates the service and re-establishes the connection without service interruption. This occurs as long as the underlying service components on which the relocation relies are enabled for relocation and restart.

Tablespace Use in Real Application Clusters

In addition to using locally managed tablespaces, you can further simplify space administration by using automatic segment-space management. Automatic segment-space management distributes instance workloads among each instance's subset of blocks for inserts. This improves RAC performance because it minimizes block transfers. To deploy automatic undo management in a RAC environment, each instance must have its own undo tablespace.

Object Creation and Performance in Real Application Clusters

As a general rule, only use DDL statements for maintenance tasks and avoid executing DDL statements during peak system operation periods. In most systems, the amount of new object creation and other DDL statements should be limited. Just as in single-instance Oracle databases, excessive object creation and deletion can increase performance overhead.

Node Addition and Deletion and the SYSAUX Tablespace in Real Application Clusters

If you add nodes to your RAC database environment, then you may need to increase the size of the SYSAUX tablespace. Conversely, if you remove nodes from your cluster database, then you may be able to reduce the size of your SYSAUX tablespace.

Using User-Mode IPC Protocols

Because Cache Fusion exploits high speed IPCs, RAC benefits from the performance gains of the latest technologies for low latency communication links used in cluster database interconnects. You can expect even greater performance gains if you use more efficient protocols, such as InfiniBand, TCP/IP, Virtual Interface Architecture (VIA) and user-mode IPCs.

Cache Fusion reduces CPU use with user-mode IPCs, also known as memory-mapped IPCs, for all platforms. If the appropriate hardware support is available, then operating system context switches are minimized beyond the basic reductions achieved with Cache Fusion alone. This also eliminates costly data copying and system calls.

If your hardware efficiently implements them, then user-mode IPCs can reduce CPU use. This is because user processes in user-mode IPCs communicate without using operating system kernels. In other words, user processes do not have to switch from user execution mode to kernel execution mode.