Preinstallation Considerations

Oracle Real Application Clusters is an 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.

Note –

In
earlier versions of Oracle, this 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.

Hardware and Software Requirements

Before
you begin the installation, note the hardware and software requirements in the subsections
that follow.

Software License Requirements

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:

For
versions of VxVM earlier than 3.5, run the vxlicense -p command.

For VxVM version
3.5, run the vxlicrep command.

If you are
using Sun StorEdgeTM QFS shared file system version 4.2, verify that you have installed
a valid license for Sun StorEdge QFS on each node. To verify that a valid license
is installed on a node, run the samcmd l command on the node.

Supported Topology Requirements

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.

Patch Installation Requirements

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.

Storage Management Requirements for Oracle Files

Sun Cluster Support for Oracle Real Application Clusters enables you to use the storage management schemes for Oracle
files that are listed in the following table. The table summarizes the types of Oracle
files that each storage management scheme can store. Ensure that you choose a combination
of storage management schemes that can store all types of Oracle files.

Table 1–2 Storage Management Schemes for Oracle
Files

Oracle File Type

Storage Management Scheme

Solaris Volume Manager for Sun Cluster

VxVM

Hardware RAID

Sun StorEdge QFS

Network Appliance NAS Devices

ASM

Cluster File System

Local Disks

RDBMS binary files

No

No

No

Yes

Yes

No

Yes

Yes

CRS binary files

No

No

No

Yes

Yes

No

Yes

Yes

Configuration files

No

No

No

Yes

Yes

No

Yes

Yes

System parameter file (SPFILE)

No

No

No

Yes

Yes

Yes

Yes

No

Alert files

No

No

No

Yes

Yes

No

Yes

Yes

Trace files

No

No

No

Yes

Yes

No

Yes

Yes

Data files

Yes

Yes

Yes

Yes

Yes

Yes

No

No

Control files

Yes

Yes

Yes

Yes

Yes

Yes

No

No

Online redo log files

Yes

Yes

Yes

Yes

Yes

Yes

No

No

Archived redo log files

No

No

No

Yes

Yes

Yes

Yes

No

Flashback log files

No

No

No

Yes

Yes

Yes

Yes

No

Recovery files

No

No

No

Yes

Yes

Yes

No

No

OCR files

Yes

Yes

Yes

Yes

Yes

No

Yes

No

CRS voting disk

Yes

Yes

Yes

Yes

Yes

No

Yes

No

Note –

Some types of files are not included in all releases of Oracle Real Application Clusters.
For information about which types of file are included in the release that you are
using, see your Oracle documentation.

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

A file system on a Network Appliance NAS device

Using Local Disks for Oracle Binary Files
and Oracle Configuration Files

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.

Using a Shared File System for Oracle Binary
Files and Oracle Configuration Files

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

Note –

VxVM is supported only on the SPARC platform.

A file system on a Network Appliance NAS device

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 short period of downtime for upgrades is acceptable, place a single copy of the
Oracle binary files and Oracle configuration files on a shared file system.

SPARC: Requirements for Using the Sun StorEdge QFS 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.

For information about how to create a Sun StorEdge QFS shared file system, see the
following documentation for Sun StorEdge QFS:

Sun StorEdge QFS File Systems for Database Files and Related Files

For database files and related files, determine whether you require one file
system for each database or multiple file systems for each database.

For simplicity of configuration and maintenance, create one file system
to store these files for all Oracle Real Application Clusters instances of the database.

To facilitate future expansion, create multiple file systems to store
these files for all Oracle Real Application Clusters instances of the database.

Note –

If you are adding storage for an existing database, you must create additional
file systems for the storage that you are adding. In this situation, distribute the
database files and related files among the file systems that you will use for the
database.

You must not store data files, control
files, online redo log files, or Oracle recovery 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.

If you are using the cluster file system with Sun Cluster 3.1, consider increasing
the desired number of secondary nodes for device groups. By increasing the desired
number of secondary nodes for device groups, you can improve the availability of your
cluster. To increase the desired number of secondary nodes for device groups, change
the numsecondaries property. For more information, see Multiported Disk Device Groups in Sun Cluster
Concepts Guide for Solaris OS.

For information about how to create cluster file systems, see the following
documentation:

Resource Groups for Oracle RAC Server Resources

Note –

If you are using Oracle 10g, no Oracle RAC server resources are required.
These resources are not required with Oracle 10g because Oracle CRS starts and shuts
down Oracle Real Application Clusters database instances. In versions of Oracle earlier than 10g,
these resources are required to enable Sun Cluster to start and shut down database
instances.

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.

Resource Groups for Oracle Listener Resources

Note –

If you are using Oracle 10g, no Oracle listener resources are required.
These resources are not required with Oracle 10g because Oracle CRS starts and shuts
down Oracle Real Application Clusters database instances. In versions of Oracle earlier than 10g,
these resources are required to enable Sun Cluster to start and shut down database
instances.

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 for One Real Application Clusters Instance

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 That Cannot Fail Over for Several Real Application Clusters Instances

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 for Several Real Application Clusters Instances

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.

One Listener for the Entire Cluster

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:

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.

SPARC: Resources for the Sun StorEdge QFS Shared File System

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?

If you are using Oracle
10g, Oracle CRS manage Real Application Clusters database instances. These database instances
must be started only after all shared file systems are mounted.
To meet this requirement, ensure that the file system that contains the Oracle CRS
voting disk is mounted only after the file systems for other
database files have been mounted. This behavior ensures that, when a node is booted,
Oracle CRS are started only after all Sun StorEdge QFS file systems are mounted.

To enable Sun Cluster to mount the file systems in the required order,
configure resource groups for the metadata servers of the file systems as follows:

Create the resources for the metadata servers in separate resource
groups.

Set the resource group for the file system that contains the Oracle
CRS voting disk to depend on the other resource groups.

For more information, see the following documentation for Sun StorEdge QFS: