Oracle Real Application Clusters is a scalable application that can run on more than one node concurrently. Sun Cluster Support for Oracle Real Application Clusters is a set of packages that, when installed, enables Oracle Real Application Clusters to run on Sun Cluster nodes. This data service also enables Oracle Real Application Clusters to be managed by using Sun Cluster commands.
In earlier versions of Oracle, this scalable application is referred to as “Oracle Parallel Server”. In this book, references to “Oracle Real Application Clusters” also apply to Oracle Parallel Server unless this book explicitly states otherwise.
This data service provides fault monitoring only to enable the status of Oracle Real Application Clusters resources to be monitored by Sun Cluster utilities. This data service does not provide automatic fault recovery because the Oracle Real Application Clusters software provides similar functionality.
Before you begin the installation, note the hardware and software requirements in the subsections that follow.
Sun Cluster Support for Oracle Real Application Clusters requires a functioning cluster with the initial cluster framework already installed. See Sun Cluster Software Installation Guide for Solaris OS for details about initial installation of cluster software.
You must configure Oracle Real Application Clusters to use the shared-disk architecture of the Sun Cluster software. In this configuration, a single database is shared among multiple instances of the Oracle Real Application Clusters software that access the database concurrently. The UNIX Distributed Lock Manager (Oracle UDLM) controls access to shared resources between cluster nodes.
To satisfy these requirements, use one storage management scheme from the following list:
Solaris Volume Manager for Sun Cluster
Solaris Volume Manager for Sun Cluster is supported only with Oracle Real Application Clusters. Solaris Volume Manager for Sun Cluster with Oracle Parallel Server is not supported.
VERITAS Volume Manager (VxVM) with the cluster feature
Hardware redundant array of independent disks (RAID) support
Sun StorEdgeTM QFS shared file system with hardware RAID support
Verify that you have obtained and installed the appropriate licenses for your software. If you install your licenses incorrectly or incompletely, the nodes might fail to boot correctly.
For example, if you are using VxVM with the cluster feature, verify that you have installed a valid license for the Volume Manager cluster feature by running one of the following commands:
Check with a Sun Enterprise Services representative for the current supported topologies for Sun Cluster Support for Oracle Real Application Clusters, cluster interconnect, storage management scheme, and hardware configurations.
Ensure that you have installed all of the applicable software patches for the Solaris Operating System, Sun Cluster, Oracle, and your volume manager. If you need to install any Sun Cluster Support for Oracle Real Application Clusters patches, you must apply these patches after you install the data service packages.
You can install the Oracle binary files and Oracle configuration files on one of the following locations.
The local disks of each cluster node
A shared file system from the following list:
The Sun StorEdge QFS shared file system
The cluster file system
Placing the Oracle binary files and Oracle configuration files on the individual cluster nodes enables you to upgrade the Oracle application later without shutting down the data service.
The disadvantage is that you then have several copies of the Oracle application binary files and Oracle configuration files to maintain and administer.
To simplify the maintenance of your Oracle installation, you can install the Oracle binary files and Oracle configuration files on a shared file system. The following shared file systems are supported:
The Sun StorEdge QFS shared file system
The cluster file system
If you use the cluster file system, decide which volume manager to use:
Solaris Volume Manager
VxVM without the cluster feature
If you put the Oracle binary files and Oracle configuration files on a shared file system, you have only one copy to maintain and manage. However, you must shut down the data service in the entire cluster to upgrade the Oracle application. If a small amount of downtime for upgrades is acceptable, place a single copy of the Oracle binary files and Oracle configuration files on a shared file system.
You can store all of the files that are associated with Oracle Real Application Clusters on the Sun StorEdge QFS shared file system.
Distribute these files among several file systems as follows:
Create one file system in the cluster to store these files:
Oracle binary files
Oracle configuration files (for example, init.ora, tnsnames.ora, listener.ora, and sqlnet.ora)
Alert files (for example, alert_sid.log)
Trace files (*.trc)
Create one file system for each database to store these files for all Oracle Real Application Clusters instances of the database:
Data files
Control files
Online redo log files
Archived redo log files
For information about how to create a Sun StorEdge QFS shared file system, see the following documentation for Sun StorEdge QFS:
Sun StorEdge QFS and Sun StorEdge SAM-FS Software Installation and Configuration Guide
Sun StorEdge QFS and Sun StorEdge SAM-FS File System Administration Guide
You can store only these files that are associated with Oracle Real Application Clusters on the cluster file system:
Oracle binary files
Oracle configuration files (for example, init.ora, tnsnames.ora, listener.ora, and sqlnet.ora)
Archived redo log files
Alert files (for example, alert_sid.log)
Trace files (*.trc)
You must not store data files, control files, or online redo log files on the cluster file system.
The input/output (I/O) performance during the writing of archived redo log files is affected by the location of the device group for archived redo log files. For optimum performance, ensure that the primary of the device group for archived redo log files is located on the same node as the Oracle Real Application Clusters database instance. This device group contains the file system that holds archived redo log files of the database instance.
For information about how to create cluster file systems, see:
Use the questions in the subsections that follow to plan the installation and configuration of Sun Cluster Support for Oracle Real Application Clusters. Write the answers to these questions in the space that is provided on the data service worksheets in “Configuration Worksheets” in Sun Cluster 3.1 Data Service Planning and Administration Guide.
Which resource groups will you use for the Oracle Real Application Clusters (RAC) server resources?
You require one resource group for each Oracle Real Application Clusters database instance. Each resource group contains the Oracle RAC server resource for the database instance.
Use the answer to this question when you perform the procedure in Registering and Configuring Oracle RAC Server Resources.
Which resource groups will you use for the Oracle listener resources?
Use the answer to this question when you perform the procedure in Registering and Configuring Oracle Listener Resources.
The resource groups depend on your configuration of Oracle listeners with Real Application Clusters database instances. For general information about possible configurations of listeners for Real Application Clusters instances, see your Oracle documentation. Example configurations are described in the subsections that follow.
One listener serves only one Real Application Clusters instance. The listener listens on the fixed Internet Protocol (IP) address of the node. The listener cannot fail over.
In this situation, configure the listener resource as follows:
Configure the listener resource and the RAC server resource in the same resource group.
Ensure that this resource group is mastered on only one node.
One listener serves several Real Application Clusters instances on the same node. The listener uses Oracle's transparent application failover (TAF) and load balancing to distribute client connections across all Real Application Clusters instances. The listener cannot fail over.
In this situation, configure the listener resource as follows:
Configure the listener resource in its own resource group.
Ensure that the listener's resource group is mastered on only one node.
Create a dependency between the listener's resource group and RAC servers' resource groups.
One listener that can fail over serves several Real Application Clusters instances on the same node. When the listener fails over to another node, the listener serves several Real Application Clusters instances on the other node.
The listener uses Oracle's TAF and load balancing to distribute client connections across all Real Application Clusters instances. To ensure fast error detection and short failover times, the listener listens on an address that is represented by a LogicalHostname resource.
In this situation, configure the listener resource as follows:
Configure the listener resource and the LogicalHostname resource in the same resource group.
Ensure that this resource group is mastered on the nodes on which Oracle Real Application Clusters is running.
For more information, see LogicalHostname Resources for Oracle Listener Resources.
One listener serves all Real Application Clusters instances on all nodes. The listener listens on an address that is represented by a LogicalHostname resource. This configuration ensures that the address is plumbed very quickly on another node after a node fails.
You can use this configuration if you configure Real Application Clusters instances to use a multithreaded server (MTS). In such a configuration, the REMOTE_LISTENERS parameter in the init.ora file specifies that each dispatcher registers with the listener on a logical IP address.
All clients connect through the one listener. The listener redirects each client connection to the least busy dispatcher. The least busy dispatcher might be on a different node from the listener.
If the listener fails, the listener's fault monitor restarts the listener. If the node where the listener is running fails, the listener is restarted on a different node. In both situations the dispatchers reregister after the listener is restarted.
If you are using one listener for the entire cluster, configure the following resources in the same resource group:
The listener resource
The LogicalHostname resource
For more information, see LogicalHostname Resources for Oracle Listener Resources.
Which LogicalHostname resources will Oracle listener resources use?
Use the answer to this question when you perform the procedure in Registering and Configuring Oracle Listener Resources.
If a cluster node that is running an instance of Oracle Real Application Clusters fails, an operation that a client application attempted might be required to time out before the operation is attempted again on another instance. If the Transmission Control Protocol/Internet Protocol (TCP/IP) network timeout is high, the client application might require a significant length of time to detect the failure. Typically, client applications require between three and nine minutes to detect such failures.
In such situations, client applications can connect to listener resources that are listening on an address that is represented by the Sun Cluster LogicalHostname resource. Configure the LogicalHostname resource and the listener resource in a separate resource group. Ensure that this resource group is mastered on the nodes on which Oracle Real Application Clusters is running. If a node fails, the resource group that contains the LogicalHostname resource and the listener resource fails over to another surviving node on which Oracle Real Application Clusters is running. The failover of the LogicalHostname resource enables new connections to be directed to the other instance of Oracle Real Application Clusters.
If you are using the Sun StorEdge QFS shared file system, answer the following questions:
Which resources will you create to represent the metadata server for the Sun StorEdge QFS shared file system?
One resource is required for each Sun StorEdge QFS metadata server.
Which resource groups will you use for these resources?
For more information, see the following documentation for Sun StorEdge QFS:
Sun StorEdge QFS and Sun StorEdge SAM-FS Software Installation and Configuration Guide
Sun StorEdge QFS and Sun StorEdge SAM-FS File System Administration Guide
Use the answers to these questions when you perform the procedure in Registering and Configuring Oracle RAC Server Resources.
Where will the system configuration files reside?
For the advantages and disadvantages of using the local file system instead of the cluster file system, see Location of Oracle Binary Files and Oracle Configuration Files.