Sun Cluster Data Service for Oracle Guide for Solaris OS

Installing and Configuring Sun Cluster HA for Oracle

This chapter explains how to install and configure Sun Cluster HA for Oracle.

This chapter contains the following sections.

Note –

You can use Sun Cluster Manager to configure this data service. See the Sun Cluster Manager online help for details.

Overview of the Installation and Configuration Process for Sun Cluster HA for Oracle

The following table summarizes the tasks for installing and configuring Sun Cluster HA for Oracle. The table also provides cross-references to detailed instructions for performing the tasks. Perform these tasks in the order that they are listed. If you are using Sun Cluster HA for Oracle with Oracle DataGuard, perform these tasks on each cluster where your Oracle database instances are running.

Table 1 Task Map: Installing and Configuring HA for Oracle


Task	Cross-Reference
Plan the Sun Cluster HA for Oracle installation and configuration	Planning the Sun Cluster HA for Oracle Installation and Configuration
Prepare the nodes and disks	Preparing the Nodes and Disks
Install the Oracle software	How to Install the Oracle Software
Verify the Oracle installation	How to Verify the Oracle Installation
Create an Oracle database	How to Create a Primary Oracle Database
Set up Oracle database permissions	How to Set Up Oracle Database Permissions
Install the Sun Cluster HA for Oracle packages	Installing the Sun Cluster HA for Oracle Packages
Register and configure Sun Cluster HA for Oracle	How to Register and Configure Sun Cluster HA for Oracle by Using Sun Cluster Maintenance commands
Verify the Sun Cluster HA for Oracle installation	Verifying the Sun Cluster HA for Oracle Installation
Tune the Sun Cluster HA for Oracle fault monitor	Tuning the Sun Cluster HA for Oracle Fault Monitors
(Optional) Customize the Sun Cluster HA for Oracle server fault monitor	Customizing the Sun Cluster HA for Oracle Server Fault Monitor
(Optional) Upgrade Sun Cluster HA for Oracle resource types	Upgrading Sun Cluster HA for Oracle Resource Types
(Optional) Change the role of a DataGuard instance	Changing the Role of a DataGuard Instance

Planning the Sun Cluster HA for Oracle Installation and Configuration

This section contains the information that you need to plan your Sun Cluster HA for Oracle installation and configuration.

Configuration Requirements

Caution –

Your data service configuration might not be supported if you do not adhere to these requirements.

Use the requirements in this section to plan the installation and configuration of Sun Cluster HA for Oracle. These requirements apply to Sun Cluster HA for Oracle only. You must meet these requirements before you proceed with your Sun Cluster HA for Oracle installation and configuration. Sun Cluster HA for Oracle can be configured to run in non-global zones if required. If you are configuring Sun Cluster HA for Oracle to run in a non-global zone, you must use a highly available local file system.

Caution –

Raw devices from Sun Cluster device groups are not supported in non-global zones.

For requirements that apply to all data services, see Configuration Guidelines for Sun Cluster Data Services in Sun Cluster Data Services Planning and Administration Guide for Solaris OS.

Oracle application files – These files include Oracle binaries, configuration files, and parameter files. You can install these files either on the local file system, the highly available local file system, or on the cluster file system.

See Configuration Guidelines for Sun Cluster Data Services in Sun Cluster Data Services Planning and Administration Guide for Solaris OS for the advantages and disadvantages of placing the Oracle binaries on the local file system, highly available local file system, and the cluster file system.
Database-related files – These files include the control file, redo logs, and data files. You must install these files on either raw devices or as regular files on the highly available local or cluster file system. Raw devices from Sun Cluster device groups are not supported in non-global zones.

Configuration Planning Questions

Use the questions in this section to plan the installation and configuration of Sun Cluster HA for Oracle. Write the answers to these questions in the space that is provided on the data service worksheets in Configuration Worksheets in Sun Cluster Data Services Planning and Administration Guide for Solaris OS.

What resource groups will you use for network addresses and application resources and the dependencies between them?
What is the logical hostname (for failover services) or shared address (for scalable services) for clients that will access the data service?
Where will the system configuration files reside?

See Configuration Guidelines for Sun Cluster Data Services in Sun Cluster Data Services Planning and Administration Guide for Solaris OS for the advantages and disadvantages of placing the Oracle binaries on the local file system rather than the cluster file system.
Does your database setup require standby instances?

If you use the clsetup utility to register and configure Sun Cluster HA for Oracle, some of these questions are answered automatically by the utility.

For information about standby databases, see your Oracle documentation.

Preparing the Nodes and Disks

This section contains the procedures that you need to prepare the nodes and disks.

How to Prepare the Nodes

Use this procedure to prepare for the installation and configuration of Oracle software.

Caution –

Perform all of the steps in this section on all the nodes. If you do not perform all of the steps on all of the nodes, the Oracle installation is incomplete. An incomplete Oracle installation causes Sun Cluster HA for Oracle to fail during startup.

Note –

Consult the Oracle documentation before you perform this procedure.

The following steps prepare your nodes and install the Oracle software.

Become superuser on all of the cluster members.

Configure the cluster file system for Sun Cluster HA for Oracle.

Caution –
Raw devices from Sun Cluster device groups are not supported in non-global zones.

If raw devices contain the databases, configure the global devices for raw device access. See the Sun Cluster Software Installation Guide for Solaris OS for information about how to configure global devices.

If you use the Solaris Volume Manager software, configure the Oracle software to use UNIX file system (UFS) logging on mirrored metadevices or raw-mirrored metadevices. See the Solaris Volume Manager documentation for more information about how to configure raw-mirrored metadevices.

If you use the Solaris Zettabyte File System (ZFS) for Oracle files, configure a highly available local ZFS. For more information, see How to Set Up the HAStoragePlus Resource Type to Make a Local Solaris ZFS Highly Available in Sun Cluster Data Services Planning and Administration Guide for Solaris OS.

Prepare the $ORACLE_HOME directory on a local or multihost disk.

Note –
If you install the Oracle binaries on a local disk, use a separate disk if possible. Installing the Oracle binaries on a separate disk prevents the binaries from overwrites during operating environment reinstallation.

On each node or zone, create an entry for the database administrator (DBA) group in the /etc/group file, and add potential users to the group.

You typically name the DBA group dba. Verify that the oracle users are members of the dba group, and add entries as necessary for other DBA users. Ensure that the group IDs are the same on all of the nodes or zones that run Sun Cluster HA for Oracle, as the following example illustrates.
dba:*:520:root,oracle
You can create group entries in a network name service (for example, NIS or NIS+). If you create group entries in this way, add your entries to the local /etc/inet/hosts file to eliminate dependency on the network name service.

On each node or zone, create an entry for the Oracle user ID (oracle).

You typically name the Oracle user ID oracle. The following command updates the /etc/passwd and /etc/shadow files with an entry for the Oracle user ID.
# useradd -u 120 -g dba -d /Oracle-home oracle
Ensure that the oracle user entry is the same on all the nodes or zones that run Sun Cluster HA for Oracle.

How to Configure Oracle Database Access Using Solaris Volume Manager

Use this procedure to configure the Oracle database using Solaris Volume Manager.

Note –

You can run this procedure only in the global zone.

Configure the disk devices for the Solaris Volume Manager software to use.

See the Sun Cluster Software Installation Guide for Solaris OS for information about how to configure the Solaris Volume Manager software.

If you use raw devices to contain the databases, run the following commands to change each raw-mirrored metadevice's owner, group, and mode.

If you do not use raw devices, do not perform this step.
1. If you create raw devices, run the following commands for each device on each node that can master the Oracle resource group.
  # chown oracle /dev/md/metaset/rdsk/dn # chgrp dba /dev/md/metaset/rdsk/dn # chmod 600 /dev/md/metaset/rdsk/dn
  metaset
  
  Specifies the name of the diskset
  
  /rdsk/dn
  
  Specifies the name of the raw disk device within the metaset diskset
2. Verify that the changes are effective.
  # ls -lL /dev/md/metaset/rdsk/dn

How to Configure Oracle Database Access Using Veritas Volume Manager

Use this procedure to configure the Oracle database using Veritas Volume Manager software.

Note –

You can run this procedure only in the global zone.

Configure the disk devices for the VxVM software to use.

See the Sun Cluster Software Installation Guide for Solaris OS for information about how to configure Veritas Volume Manager.

If you use raw devices to contain the databases, run the following commands on the current disk-group primary to change each device's owner, group, and mode.

If you do not use raw devices, do not perform this step.
1. If you create raw devices, run the following command for each raw device.
  # vxedit -g diskgroup set user=oracle group=dba mode=600 volume
  diskgroup
  
  Specifies the name of the disk group
  
  volume
  
  Specifies the name of the raw device within the disk group
2. Verify that the changes are effective.
  # ls -lL /dev/vx/rdsk/diskgroup/volume
3. Synchronize the device group with the cluster to keep the VxVM namespace consistent throughout the cluster.
  # cldevicegroup sync diskgroup

Installing the Oracle Software

This section contains the procedure that you need to install Oracle software.

How to Install the Oracle Software

Become superuser on a cluster member.

If you plan to install the Oracle software on a cluster file system, start the Sun Cluster software and become the owner of the device group.

If you plan to install the Oracle software at another location, omit this step.

For more information about installation locations, see Preparing the Nodes and Disks.

Install the Oracle software.

Before you start the Oracle installation, ensure that the system resources required for Oracle have been configured. Log in as oracle to ensure ownership of the entire directory before you perform this step. See the appropriate Oracle installation and configuration guides for instructions about how to install Oracle software.
- If you are using the Solaris 9 OS, modify /etc/system file of each node as you would in standard Oracle installation procedures. Reboot each node so that the changes are effective.
- If you are using the Solaris 10 OS, you could use Solaris Resource Management (SRM) to ensure that the kernel parameters are set to at least the minimum values that Oracle requires. For more information about setting the Oracle kernel parameters, see How to Set the Oracle Kernel Parameters. After the system resources have been configured for Oracle you can start the installation itself.

(Optional) If you are using Sun Cluster HA for Oracle with Oracle 10g R1, prevent the Oracle cssd daemon from being started. If you are using Sun Cluster HA for Oracle with Oracle 10g R2, omit this step.

Remove the entry for the Oracle cssd daemon from the /etc/inittab file on the node where the Oracle software is installed. To remove this entry, remove the following line from the /etc/inittab file:
```
h1:23:respawn:/etc/init.d/init.cssd run >/dev/null 2>&1 > </dev/null
```
Sun Cluster HA for Oracle does not require the Oracle cssd daemon. Therefore, removal of this entry does not affect the operation of Oracle 10g R1 with Sun Cluster HA for Oracle. If your Oracle installation changes so that the Oracle cssd daemon is required, restore the entry for this daemon to the /etc/inittab file.

Caution –
If you are using Oracle 10g R1Real Application Clusters, do not remove the entry for the cssd daemon from the /etc/inittab file.

If you remove the entry for the Oracle cssd daemon from the /etc/inittab file, you prevent unnecessary error messages from being displayed. Otherwise, an attempt by the init(1M) command to start the Oracle cssd daemon might cause such error messages to be displayed. These error messages are displayed if the Oracle binary files are installed on a highly available local file system or on the cluster file system. The messages are displayed repeatedly until the file system where the Oracle binary files are installed is mounted.

These error messages are as follows:
INIT: Command is respawning too rapidly. Check for possible errors. id: h1 "/etc/init.d/init.cssd run >/dev/null 2>&1 >/dev/null"
Waiting for filesystem containing $CRSCTL.
If you are using Sun Cluster HA for Oracle on the x86 platform, unnecessary error messages about the unavailability of the UNIX Distributed Lock Manager (Oracle UDLM) might also be displayed.

These messages are displayed if the following events occur:
- A node is running in noncluster mode. In this situation, file systems that Sun Cluster controls are never mounted.
- A node is booting. In this situation, the messages are displayed repeatedly until Sun Cluster mounts the file system where the Oracle binary files are installed.
- Oracle is started on or fails over to a node or zone where the Oracle installation was not originally run. In such a configuration, the Oracle binary files are installed on a highly available local file system. In this situation, the messages are displayed on the console of the node or zone where the Oracle installation was run.

How to Set the Oracle Kernel Parameters

The default project is modified to contain the resources required for Oracle as the RGM uses the default project for running the data service. If you want to use a specific SRM project for running Oracle, you must create that project and configure the system resources in that project using the same procedure. Specify the project name instead of default. When you configure the resource group or resource for the Oracle server, specify that project name in the corresponding property of the resource group or resource.

Display the settings for the default project.
phys-X# prctl -i project default

If no kernel parameters are set, or if any kernel parameters are not set to the minimum required value for Oracle as shown in the following table, set the parameter.

phys-X# projmod -s -K "parameter=(priv,value,deny)" default

Oracle Kernel Parameter	Minimum Required Value
`process.max-sem-nsems`	256
`project.max-sem-ids`	100
`project.max-shm-ids`	100
`project.max-shm-memory`	4294967295

See the Oracle10g Installation Guide for more information about these parameters.

Verify the new settings.
phys-X# prctl -i project default

Verifying the Oracle Installation and Configuration

This section contains the procedure that you need to verify the Oracle installation and configuration.

How to Verify the Oracle Installation

This procedure does not verify that your application is highly available because you have not yet installed your data service.

Confirm that the owner, group, and mode of the $ORACLE_HOME/bin/oracle file are as follows:
- Owner: oracle
- Group: dba
- Mode: -rwsr-s--x
# ls -l $ORACLE_HOME/bin/oracle

Verify that the listener binaries exist in the $ORACLE_HOME/bin directory.

Next Steps

When you have completed the work in this section, go to Creating an Oracle Database.

Creating an Oracle Database

After verifying the Oracle installation and configuration, create the Oracle databases that you require. If you are using Oracle without standby databases, perform the procedure How to Create a Primary Oracle Database. This procedure is not required for any additional databases that you might create and configure. If you are using Oracle DataGuard, create the following database instances:

Primary database instance. For instructions for creating a primary database, see How to Create a Primary Oracle Database.
Standby database instances. A standby database instance can be either a physical standby database instance or a logical standby database instance. For instructions for creating standby database instances, see your Oracle documentation.

How to Create a Primary Oracle Database

Prepare database configuration files.

Place all of the database-related files (data files, redo log files, and control files) on either shared raw global devices or on the cluster file system. See Preparing the Nodes and Disks for information about installation locations.

Note –
If the database exists in the non-global zone, do not place the database-related files on the shared raw devices.

Within the init$ORACLE_SID.ora or config$ORACLE_SID.ora file, you might need to modify the assignments for control_files and background_dump_dest to specify the locations of the control files and alert files.

Note –
If you use Solaris authentication for database logins, set the remote_os_authent variable in the init$ORACLE_SID.ora file to True.

Start the creation of the database by using one utility from the following list:
- The Oracle installer
- The Oracle sqlplus(1M) command
- The Oracle Database Configuration Assistant
During creation, ensure that all the database-related files are placed in the appropriate location, either on shared global devices , on the cluster file system, or on a highly available local file system.

Verify that the file names of your control files match the file names in your configuration files.

Create the v$sysstat view.

Run the catalog scripts that create the v$sysstat view. The Sun Cluster HA for Oracle fault monitor uses this view.

Next Steps

When you have completed the work in this section, go to Setting Up Oracle Database Permissions.

Setting Up Oracle Database Permissions

Caution –

Do not perform the steps in this section for an Oracle physical standby database.

Perform the procedure in this section to set up database permissions for an Oracle primary database or an Oracle logical standby database.

How to Set Up Oracle Database Permissions

Enable access for the user and password to be used for fault monitoring.

To use the Oracle authentication method, grant to this user authority on the v_$sysstat view and the v_$archive_dest view.

# sqlplus  "/ as sysdba"

sql>	create user user identified by passwd;
sql>	alter user user default tablespace system quota 1m on system;
sql>	grant select on v_$sysstat to user;
sql>	grant select on v_$archive_dest to user;
sql>	grant select on v_$database to user;
sql>	grant create session to user;
sql>	grant create table to user;

sql>	exit;
#

You can use this method for all the supported Oracle releases.

To use the Solaris authentication method, perform the following steps:

Confirm that the remote_os_authent parameter is set to TRUE.

# sqlplus  "/ as sysdba"
sql> show parameter remote_os_authent

NAME                       TYPE        VALUE
---------------------- ----------- ---------------
remote_os_authent         boolean     TRUE

Determine the setting of the os_authent_prefix parameter.

# sql>  show parameter os_authent_prefix

NAME                       TYPE        VALUE
---------------------- ----------- ---------------
os_authent_prefix         string      ops$

Grant permission for the database to use Solaris authentication.

sql> create user prefix user identified by externally default 
tablespace system quota 1m on system;
sql> grant connect, resource to prefix user;
sql> grant select on v_$sysstat to prefix user;
sql> grant select on v_$archive_dest to prefix user;
sql> grant create session to prefix user;
sql> grant create table to prefix user;
sql> exit;

#

The replaceable items in these commands are as follows:

prefix is the setting of the os_authent_prefix parameter. The default setting of this parameter is ops$.
user is the user for whom you are enabling Solaris authentication. Ensure that this user owns the files under the $ORACLE_HOME directory.

Note –

Do not type a space between prefix and user.

Configure NET8 for the Sun Cluster software.

The listener.ora file must be accessible from all the nodes or zones that are in the cluster. Place these files either under the cluster file system or in the local file system of each node or zone that can potentially run the Oracle resources.

Note –

If you place the listener.ora file in a location other than the /var/opt/oracle directory or the $ORACLE_HOME/network/admin directory, you must specify the TNS_ADMIN variable or an equivalent Oracle variable in a user-environment file. For information about Oracle variables, see the Oracle documentation. You must also run the clresource(1CL) command to set the resource extension parameter User_env, which sources the user-environment file. See SUNW.oracle_listener Extension Properties or SUNW.oracle_server Extension Properties for format details.

Sun Cluster HA for Oracle imposes no restrictions on the listener name—it can be any valid Oracle listener name.

The following code sample identifies the lines in listener.ora that are updated.

LISTENER =
	(ADDRESS_LIST =
			(ADDRESS =
				(PROTOCOL = TCP) 
					(HOST = logical-hostname) <- use logical hostname
				(PORT = 1527)
			)
	)
.
.
SID_LIST_LISTENER =
	.
			.
						(SID_NAME = SID) <- Database name, 
default is ORCL

The following code sample identifies the lines in tnsnames.ora that are updated on client machines.

service_name =
	.
			.
						(ADDRESS = 
								(PROTOCOL = TCP)
								(HOST = logicalhostname)	<- logical hostname
								(PORT = 1527) <- must match port in LISTENER.ORA
						)
				)
				(CONNECT_DATA =
						(SID = <SID>)) <- database name, default is ORCL

The following example shows how to update the listener.ora and tnsnames.ora files for the following Oracle instances.

Instance	Logical Host	Listener
`ora8`	`hadbms3`	`LISTENER-ora8`
`ora9`	`hadbms4`	`LISTENER-ora9`

The corresponding listener.ora entries are the following entries.

LISTENER-ora9 =
	(ADDRESS_LIST =
			(ADDRESS =
				(PROTOCOL = TCP)
				(HOST = hadbms4)
				(PORT = 1530)
			)
		)
SID_LIST_LISTENER-ora9 =
	(SID_LIST =
			(SID_DESC =
				(SID_NAME = ora9)
			)
		)
LISTENER-ora8 =
  (ADDRESS_LIST =
    (ADDRESS= (PROTOCOL=TCP) (HOST=hadbms3)(PORT=1806))
  )
SID_LIST_LISTENER-ora8 =
  (SID_LIST =
     (SID_DESC =
			(SID_NAME = ora8)
		 )	
  )

The corresponding tnsnames.ora entries are the following entries.

ora8 =
(DESCRIPTION =
   (ADDRESS_LIST = 
			(ADDRESS = (PROTOCOL = TCP) 
			(HOST = hadbms3) 
			(PORT = 1806))
   	)    
	(CONNECT_DATA = (SID = ora8))
)
ora9 =
(DESCRIPTION =
  (ADDRESS_LIST =
        (ADDRESS = 
				(PROTOCOL = TCP) 
				(HOST = hadbms4) 
				(PORT = 1530))
  )
  	(CONNECT_DATA = (SID = ora9))
)

Verify that the Sun Cluster software is installed and running on all the nodes.
# cluster status +

Next Steps

Go to Installing the Sun Cluster HA for Oracle Packages to install the Sun Cluster HA for Oracle packages.

Installing the Sun Cluster HA for Oracle Packages

If you did not install the Sun Cluster HA for Oracle packages during your initial Sun Cluster installation, perform this procedure to install the packages. To install the packages, use the Sun Java Enterprise System Common Installer.

Note –

You need to install the Sun Cluster HA for Oracle packages in the global cluster and not in the zone cluster.

How to Install the Sun Cluster HA for Oracle Packages

Perform this procedure on each cluster node where you are installing the Sun Cluster HA for Oracle packages.

You can run the Sun Java Enterprise System Common Installer with a command-line interface (CLI) or with a graphical user interface (GUI). The content and sequence of instructions in the CLI and the GUI are similar.

Note –

Even if you plan to configure this data service to run in non-global zones, install the packages for this data service in the global zone. The packages are propagated to any existing non-global zones and to any non-global zones that are created after you install the packages.

Before You Begin

Ensure that you have the Sun Java^TM Availability Suite DVD-ROM.

If you intend to run the Sun Java Enterprise System Common Installer with a GUI, ensure that your DISPLAY environment variable is set.

On the cluster node where you are installing the data service packages, become superuser.

Load the Sun Java Availability Suite DVD-ROM into the DVD-ROM drive.

If the Volume Management daemon vold(1M) is running and configured to manage DVD-ROM devices, the daemon automatically mounts the DVD-ROM on the /cdrom directory.

Change to the Sun Java Enterprise System Common Installer directory of the DVD-ROM.
- If you are installing the data service packages on the SPARC® platform, type the following command:
  # cd /cdrom/cdrom0/Solaris_sparc
- If you are installing the data service packages on the x86 platform, type the following command:
  # cd /cdrom/cdrom0/Solaris_x86

Start the Sun Java Enterprise System Common Installer.
# ./installer

When you are prompted, accept the license agreement.

If any Sun Java Enterprise System components are installed, you are prompted to select whether to upgrade the components or install new software.

From the list of Sun Cluster agents under Availability Services, select the data service for Oracle.

If you require support for languages other than English, select the option to install multilingual packages.

English language support is always installed.

When prompted whether to configure the data service now or later, choose Configure Later.

Choose Configure Later to perform the configuration after the installation.

Follow the instructions on the screen to install the data service packages on the node.

The Sun Java Enterprise System Common Installer displays the status of the installation. When the installation is complete, the wizard displays an installation summary and the installation logs.

(GUI only) If you do not want to register the product and receive product updates, deselect the Product Registration option.

The Product Registration option is not available with the CLI. If you are running the Sun Java Enterprise System Common Installer with the CLI, omit this step.

Exit the Sun Java Enterprise System Common Installer.

Unload the Sun Java Availability Suite DVD-ROM from the DVD-ROM drive.
1. To ensure that the DVD-ROM is not being used, change to a directory that does not reside on the DVD-ROM.
2. Eject the DVD-ROM.
  # eject cdrom

Next Steps

See Registering and Configuring Sun Cluster HA for Oracle to register Sun Cluster HA for Oracle and to configure the cluster for the data service.

Registering and Configuring Sun Cluster HA for Oracle

Tools for Registering and Configuring Sun Cluster HA for Oracle

Sun Cluster provides the following tools for registering and configuring Sun Cluster HA for Oracle:

The clsetup(1CL) utility. For more information, see How to Register and Configure Sun Cluster HA for Oracle by Using the clsetup Utility.
Sun Cluster Manager. For more information, see the Sun Cluster Manager online help.
Sun Cluster maintenance commands. For more information, see How to Register and Configure Sun Cluster HA for Oracle by Using Sun Cluster Maintenance commands.

The clsetup utility and Sun Cluster Manager each provide a wizard for configuring Sun Cluster HA for Oracle. The wizards reduce the possibility for configuration errors that might result from command syntax errors or omissions. These wizards also ensure that all required resources are created and that all required dependencies between resources are set.

Setting Sun Cluster HA for Oracle Extension Properties

Use the extension properties in Sun Cluster HA for Oracle Extension Properties to create your resources. To set an extension property of a resource, include the option -p property=value in the clresource(1CL) command that creates or modifies the resource. Use the procedure in Chapter 2, Administering Data Service Resources, in Sun Cluster Data Services Planning and Administration Guide for Solaris OS to configure the extension properties if you have already created your resources. You can update some extension properties dynamically. You can update others, however, only when you create or disable a resource. The Tunable entries indicate when you can update each property. See Appendix B, Standard Properties, in Sun Cluster Data Services Planning and Administration Guide for Solaris OS for details about all Sun Cluster properties.

SUNW.oracle_server Extension Properties describes the extension properties that you can set for the Oracle server. For the Oracle server, you are required to set only the following extension properties:

ORACLE_HOME
ORACLE_SID
Alert_log_file
Connect_string

How to Register and Configure Sun Cluster HA for Oracle by Using the `clsetup` Utility

This procedure provides the long forms of the Sun Cluster maintenance commands. Most commands also have short forms. Except for the forms of the command names, the commands are identical. For a list of the commands and their short forms, see Appendix A, Sun Cluster Object-Oriented Commands, in Sun Cluster 3.1 - 3.2 Hardware Administration Manual for Solaris OS

Note –

The clsetup utility does not support configuration of Sun Cluster HA for Oracle with ZFS.

Before You Begin

Ensure that the following prerequisites are met:

The volume manager of the cluster is configured to provide volumes on shared storage that are accessible from any node where Oracle could potentially run.
Raw devices and file systems on the storage volumes that Oracle will use for its database are created.
The Oracle software is installed to be accessible from all nodes or zones where Oracle could potentially run.
Kernel variables for the UNIX operating system are configured for Oracle.
The Oracle software is configured for all nodes or zones that could potentially run Oracle.
The data service packages are installed.

Ensure that you have the following information:

The names of the cluster nodes or zones that master the data service.
The logical hostname that clients use to access the data service. Normally, you set up this IP address when you install the cluster. See the Sun Cluster Concepts Guide for Solaris OS for details about network resources.
The path to the Oracle application binaries for the resources that you plan to configure.
The database type.

Become superuser on any cluster node.

Start the clsetup utility.
# clsetup
The clsetup main menu is displayed.

Type the number that corresponds to the option for data services and press Return.

The Data Services menu is displayed.

Type the number that corresponds to the option for configuringSun Cluster HA for Oracle and press Return.

The clsetup utility displays the list of prerequisites for performing this task.

Verify that the prerequisites are met, and press Return.

The clsetup utility displays a list of the cluster nodes.

Select the nodes or zones where you require Oracle to run.
- To accept the default selection of all listed nodes or zones in an arbitrary order, press Return.
- To select a subset of the listed nodes or zones, type a comma-separated or space-separated list of the numbers that correspond to the nodes or zones. Then press Return.
  
  Ensure that the nodes or zones are listed in the order in which the nodes or zones are to appear in the node list of the resource group in which the Oracle resource is to be placed. The first node or zone in the list is the primary node or zone of this resource group.
- To select all nodes or zones in a particular order, type a comma-separated or space-separated ordered list of the numbers that correspond to the nodes or zones and press Return.
  
  Ensure that the nodes or zones are listed in the order in which the nodes or zones are to appear in the node list of the resource group in which the Oracle resource is to be placed. The first node or zone in the list is the primary node or zone of this resource group.

To confirm your selection of nodes or zones, type d and press Return.

The clsetup utility displays the types of Oracle components that are to be configured.

Type the numbers of the Oracle components you want to configure and press Return.

The clsetup utility lists the Oracle home directory.

Specify the Oracle home directory for your installation of the Oracle software.
- If the directory is listed, select the directory as follows:
  1. Type the number that corresponds the directory that you are selecting.
    
    The clsetup utility displays a list of Oracle system identifiers that are configured on the cluster. The utility also prompts you to specify the system identifier for your installation of Oracle.
- If the directory is not listed, specify the directory explicitly.
  1. Type e and press Return.
    
    The clsetup utility prompts you for the Oracle home directory.
  2. Type the full path to the Oracle home directory and press Return.
    
    The clsetup utility displays a list of Oracle system identifiers that are configured on the cluster. The utility also prompts you to specify the system identifier for your installation of Oracle.

Specify the Oracle SID of the Oracle database that you are configuring.
- If the SID is listed, select the SID as follows:
  1. Type the number that corresponds the SID that you are selecting.
    
    The clsetup utility displays the properties of the Sun Cluster resources that the utility will create.
- If the SID is not listed, specify the SID explicitly.
  1. Type e and press Return.
    
    The clsetup utility prompts you for the SID.
  2. Type the SID and press Return.
    
    The clsetup utility displays the properties of the Sun Cluster resources that the utility will create.
The clsetup utility displays the properties of the Sun Cluster resources that the utility will create.

If you require a different name for any Sun Cluster resources properties, change each name as follows.
1. Type the number that corresponds to the name that you are changing and press Return.
  
  The clsetup utility displays a screen where you can specify the new name.
2. At the New Value prompt, type the new name and press Return.
The clsetup utility returns you to the list of the properties of the Sun Cluster resource that the utility will create.

To confirm your selection of Sun Cluster resource properties, type d and press Return.

The clsetup utility displays a list of existing storage resources. If no storage resources are available, the clsetup utility displays a list of shared storage types where data is to be stored.

Type the numbers that correspond to type of shared storage that you are using for storing the data and press Return.

The clsetup utility displays the file-system mount points that are configured in the cluster.

Select the file system mount points as follows.
- To accept the default selection of all listed file-system mount points in an arbitrary order, type a. Then press Return.
- To select a subset of the listed filea system mount points, type a comma-separated or space-separated list of the numbers that correspond to the file-system mount points. Then press Return.
The clsetup utility displays the global disk sets and device groups that are configured in the cluster.

Select the device groups as follows.
- To accept the default selection of all listed device groups in an arbitrary order, type a and press Return.
- To select a subset of the listed device groups, type a comma-separated or space-separated list of the numbers that correspond to the device groups and press Return.
The clsetup utility returns to you the list of highly available storage resources.

Type a comma-separated or space-separated list of the numbers that correspond to the storage resources that your data service requires, and press Return.

To confirm your selection of Sun Cluster storage resources, type d and press Return.

The clsetup utility displays all the existing logical hostname resources in the cluster. If there are no logical hostname resources available, the clsetup utility prompts for the logical hostname that the resource is to make highly available.

Specify the logical hostname and press Return.

The clsetup utility returns to you the list of available logical hostname resources.

Type a comma-separated or space-separated list of the numbers that correspond to the logical hostname resources that your data service requires, and press Return.

To confirm your selection of Sun Cluster logical hostname resources, type d and press Return.

The clsetup utility displays the names of the Sun Cluster objects that the utility will create.

If you require a different name for any Sun Cluster objects, change each name as follows.
- Type the number that corresponds to the name that you are changing and press Return.
  
  The clsetup utility displays a screen where you can specify the new name.
- At the New Value prompt, type the new name and press Return.
  
  The clsetup utility returns you to the list of the names of the Sun Cluster objects that the utility will create.

To confirm your selection of Sun Cluster object names, type d and press Return.

To create the configuration, type c and Press Return.

The clsetup utility displays a progress message to indicate that the utility is running commands to create the configuration. When configuration is complete, the clsetup utility displays the commands that the utility ran to create the configuration.

Press Return to continue.

(Optional) Type q and press Return repeatedly until you quit the clsetup utility.

If you prefer, you can leave the clsetup utility running while you perform other required tasks before using the utility again.

How to Register and Configure Sun Cluster HA for Oracle by Using Sun Cluster Maintenance commands

Before You Begin

Ensure that the following prerequisites are met:

The volume manager of the cluster is configured to provide volumes on shared storage that are accessible from any node where Oracle could potentially run.
Raw devices and file systems on the storage volumes that Oracle will use for its database are created.
The Oracle software is installed to be accessible from all nodes or zones where Oracle could potentially run.
Kernel variables for the UNIX operating system are configured for Oracle.
The Oracle software is configured for all nodes or zones that could potentially run Oracle.
The data service packages are installed.

Ensure that you have the following information:

The names of the cluster nodes or zones that master the data service.
The logical hostname that clients use to access the data service. Normally, you set up this IP address when you install the cluster. See the Sun Cluster Concepts Guide for Solaris OS for details about network resources.
The path to the Oracle application binaries for the resources that you plan to configure.
The database type.

On a cluster member, become superuser or assume a role that provides solaris.cluster.modify and solaris.cluster.admin RBAC authorizations.

Register the resource types for the data service.

For Sun Cluster HA for Oracle, you register two resource types, SUNW.oracle_server and SUNW.oracle_listener, as follows.
# clresourcetype register SUNW.oracle_server # clresourcetype register SUNW.oracle_listener

Create a failover resource group to hold the network and application resources.

This step is not required if you use the Solaris ZFS, because the resource group was created when the highly available local ZFS was configured. The resources that are created in other steps in this procedure are to be added to this resource group.

You can optionally select the set of nodes or zones on which the data service can run with the -n option, as follows.
# clresourcegroup create [-n node-zone-list] resource-group
-n node-zone-list

Specifies a comma-separated, ordered list of zones that can master this resource group. The format of each entry in the list is node:zone. In this format, node specifies the name or ID of a node and zone specifies the name of a non-global Solaris zone. To specify the global zone, or to specify a node without non-global zones, specify only node.

The order in this list determines the order in which the nodes or zones are considered primary during failover. This list is optional. If you omit this list, the global zone of each cluster node can master the resource group.

resource-group

Specifies the name of the resource group. This name can be your choice but must be unique for resource groups within the cluster.

Verify that all of the network resources that you use have been added to your name service database.

You should have performed this verification during the Sun Cluster installation.

Note –
Ensure that all of the network resources are present in the server's and client's /etc/inet/hosts file to avoid any failures because of name service lookup.

Add a logical hostname resource to the failover resource group.
# clreslogicalhostname create -g resource-group [-h logicalhostname] logicalhotname-rs
logicalhostname

Specifies a logical hostname. This logical hostname must present in your name service database. If logicalhostname and logicalhostname-rs are identical, logicalhostname is optional.

logicalhostname-rs

Specifies the name that you are assigning to the logical hostname resource that you are creating.

Add a resource of type SUNW.HAStoragePlus to the failover resource group.

Caution –
Raw devices from Sun Cluster device groups are not supported in non-global zones.

Note –
The SUNW.HAStoragePlus resource type must be version 4 if it is to be supported in non-global zones.

Note –
If you use the Solaris ZFS for Oracle files, omit this step. The SUNW.HAStoragePlus resource was created when the highly available local ZFS was configured. For more information, see How to Prepare the Nodes.
# clresource create -g resource-group -t SUNW.HAStoragePlus \ -p GlobalDevicePaths=device-path \ -p FilesystemMountPoints=mount-point-list \ -p AffinityOn=TRUE hastp-rs
You must set either the GlobalDevicePaths extension property or the FilesystemMountPoints extension property:
- If your database is on a raw device, set the GlobalDevicePaths extension property to the global device path.
- If your database is on the cluster file system, specify mount points of the cluster file system and the local file system.
Note –
AffinityOn must be set to TRUE and the local file system must reside on global disk groups to be failover.

The resource is created in the enabled state.

Bring online the failover resource group in a managed state on a cluster node or zone.
# clresourcegroup online -M resource-group
-M

Places the resource group that is brought online in a managed state.

Create Oracle application resources in the failover resource group.

Oracle server resource:

# clresource create  -g resourcegroup \
-t SUNW.oracle_server \ 
-p Connect_string=user/passwd \
-p ORACLE_SID=instance \
-p ORACLE_HOME=Oracle-home \
-p Alert_log_file=path-to-log \
-p Restart_type=entity-to-restart \
[-p Dataguard_role=role] \
[-p Standby_mode=mode] \-p resource_dependencies=storageplus-resource \
 resource

Oracle listener resource:

# clresource create -g resource-group \
-t SUNW.oracle_listener \ 
-p LISTENER_NAME=listener \
-p ORACLE_HOME=Oracle-home \
-p resource_dependencies=storageplus-resource resource

-g resource-group

Specifies the name of the resource group into which the resources are to be placed.

-t SUNW.oracle_server/listener

Specifies the type of the resource to add.

-p Alert_log_file=path-to-log

Sets the path under $ORACLE_HOME for the server message log.

-p Connect_string=user/passwd

Specifies the user and password that the fault monitor uses to connect to the database. These settings must agree with the permissions that you set up in How to Set Up Oracle Database Permissions. If you use Solaris authorization, type a slash (/) instead of the user name and password.

-p ORACLE_SID=instance

Sets the Oracle system identifier.

-p LISTENER_NAME=listener

Sets the name of the Oracle listener instance. This name must match the corresponding entry in listener.ora.

-p ORACLE_HOME=Oracle-home

Sets the path to the Oracle home directory.

-p Restart_type=entity-to-restart

Specifies the entity that the server fault monitor restarts when the response to a fault is restart. Set entity-to-restart as follows:

To specify that only this resource is restarted, set entity-to-restart to RESOURCE_RESTART. By default, only this resource is restarted.
To specify that all resources in the resource group that contains this resource are restarted, set entity-to-restart to RESOURCE_GROUP_RESTART.

If you set entity-to-restart to RESOURCE_GROUP_RESTART, all other resources (such as Apache or DNS) in the resource group are restarted, even if they are not faulty. Therefore, include in the resource group only the resources that you require to be restarted when the Oracle server resource is restarted.

-p Dataguard_role=role

Specifies the role of the database instance. Change role as follows:

To create a resource for a primary database instance that does not have standby instances configured, change role to NONE. This value is the default value.
To create a resource for a primary database instance that has standby database instances configured, change role to PRIMARY.
To create a resource for a standby database instance, change role to STANDBY.

-p Standby_mode=mode

Specifies the mode for the standby database instance. If you change Dataguard_role to NONE or PRIMARY, the value of the Standby_mode is ignored.

To specify a logical standby database, change mode to LOGICAL. This value is the default value.
To specify a physical standby database, change mode to PHYSICAL.

resource

Specifies the name of the resource that you are creating.

Note –

Optionally, you can set additional extension properties that belong to the Oracle data service to override their default values. See Setting Sun Cluster HA for Oracle Extension Properties for a list of extension properties.

The resources are created in the enabled state.

Example 1 Registering Sun Cluster HA for Oracle to Run in the Global Zone

The following example shows how to register Sun Cluster HA for Oracle on a two-node cluster.

Cluster Information
Node names: phys-schost-1, phys-schost-2
Logical Hostname: schost-1
Resource group: resource-group-1 (failover resource group)
HAStoragePlus Resource: hastp-rs
Oracle Resources: oracle-server-1, oracle-listener-1
Oracle Instances: ora-lsnr (listener), ora-srvr (server)
 
(Create the failover resource group to contain all of the resources.)
# clresourcegroup create resource-group-1
 
(Add the logical hostname resource to the resource group.)
# clreslogicalhostname create -g resource-group-1 schost-1 
 
(Register the SUNW.HAStoragePlus resource type.)
# clresourcetype register SUNW.HAStoragePlus

(Add a resource of type SUNW.HAStoragePlus to the resource group.)
# clresource create -g resource-group-1 -t SUNW.HAStoragePlus \
-p FileSystemMountPoints=/global/oracle,/global/ora-data/logs,local/ora-data -p AffinityOn=TRUE hastp-rs

(Bring the resource group online in a managed state
# clresourcegroup online -M resource-group-1

(Register the Oracle resource types.)
# clresourcetype register SUNW.oracle_server
# clresourcetype register SUNW.oracle_listener
 
(Add the Oracle application resources to the resource group.)
# clresource create -g resource-group-1 \
-t SUNW.oracle_server -p ORACLE_HOME=/global/oracle \
-p Alert_log_file=/global/oracle/message-log \
-p ORACLE_SID=ora-srvr -p Connect_string=scott/tiger \
-p Dataguard_role=STANDBY -p Standby_mode=PHYSICAL oracle-server-1
 
# clresource create -g resource-group-1 \
-t SUNW.oracle_listener -p ORACLE_HOME=/global/oracle \
-p LISTENER_NAME=ora-lsnr oracle-listener-1

Example 2 Registering Sun Cluster HA for Oracle to Run in the Non-Global Zone

The following example shows how to register Sun Cluster HA for Oracle on a two-node cluster.

Cluster Information
Node names: phys-schost-1, phys-schost-2
Non-global zone names: sc1zone1, sc2zone1
Logical Hostname: schost-1
Resource group: resource-group-1 (failover resource group)
HAStoragePlus Resource: hastp-rs
Oracle Resources: oracle-server-1, oracle-listener-1
Oracle Instances: ora-lsnr (listener), ora-srvr (server)
 
(Create the failover resource group to contain all of the resources.)
# clresourcegroup create phys-schost-1:sc1zone1,phys-schost-2:sc2zone1 resource-group-1
 
(Add the logical hostname resource to the resource group.)
# clreslogicalhostname create -g resource-group-1 schost-1 
 
(Register the SUNW.HAStoragePlus resource type.)
# clresourcetype register SUNW.HAStoragePlus

(Add a resource of type SUNW.HAStoragePlus to the resource group.)
# clresource create -g resource-group-1 -t SUNW.HAStoragePlus \
-p FileSystemMountPoints=/global/oracle,/global/ora-data/logs,local/ora-data -p AffinityOn=TRUE hastp-rs

(Bring the resource group online in a managed state
# clresourcegroup online -M resource-group-1

(Register the Oracle resource types.)
# clresourcetype register SUNW.oracle_server
# clresourcetype register SUNW.oracle_listener
 
(Add the Oracle application resources to the resource group.)
# clresource create -g resource-group-1 \
-t SUNW.oracle_server -p ORACLE_HOME=/global/oracle \
-p Alert_log_file=/global/oracle/message-log \
-p ORACLE_SID=ora-srvr -p Connect_string=scott/tiger \
-p Dataguard_role=STANDBY -p Standby_mode=PHYSICAL oracle-server-1
 
# clresource create -g resource-group-1 \
-t SUNW.oracle_listener -p ORACLE_HOME=/global/oracle \
-p LISTENER_NAME=ora-lsnr oracle-listener-1

Where to Go From Here

Go to Verifying the Sun Cluster HA for Oracle Installation after you register and configure Sun Cluster HA for Oracle.

Verifying the Sun Cluster HA for Oracle Installation

Perform the following verification tests to make sure that you have correctly installed Sun Cluster HA for Oracle.

These sanity checks ensure that all the nodes or zones that run Sun Cluster HA for Oracle can start the Oracle instance and that the other nodes or zones in the configuration can access the Oracle instance. Perform these sanity checks to isolate any problems in starting the Oracle software from Sun Cluster HA for Oracle.

How to Verify the Sun Cluster HA for Oracle Installation

Set the environment variables ORACLE_SID and ORACLE_HOME.

Confirm that you can start the Oracle instance from this node or zone.

Confirm that you can connect to the Oracle instance.

Use the sqlplus command with the user/password variable that is defined in the connect_string property.
# sqlplus user/passwd@tns_service

Shut down the Oracle instance.

The Sun Cluster software restarts the Oracle instance because the Oracle instance is under Sun Cluster control.

Switch the resource group that contains the Oracle database resource to another cluster member.
# clresourcegroup switch -n node-zone-list resource-group
-n node-zone-list

Specifies a comma-separated, ordered list of zones that can master this resource group. The format of each entry in the list is node:zone. In this format, node specifies the name or ID of a node and zone specifies the name of a non-global Solaris zone. To specify the global zone, or to specify a node without non-global zones, specify only node.

The order in this list determines the order in which the nodes or zones are considered primary during failover. This list is optional. If you omit this list, the global zone of each cluster node can master the resource group.

resource-group

Specifies the name of the resource group that you are switching.

Repeat Step 3 and Step 4 to confirm interactions with the Oracle instance.

Oracle Clients

Clients must always refer to the database by using the network resource, not the physical hostname. The network resource is an IP address that can move between physical nodes during failover. The physical hostname is a machine name.

For example, in the tnsnames.ora file, you must specify the network resource as the host on which the database instance is running. The network resource is a logical hostname or a shared address. See How to Set Up Oracle Database Permissions.

Note –

Oracle client-server connections cannot survive a Sun Cluster HA for Oracle switchover. The client application must be prepared to handle disconnection and reconnection or recovery as appropriate. A transaction monitor might simplify the application. Further, Sun Cluster HA for Oracle node recovery time is application dependent.

Location of Sun Cluster HA for Oracle Log Files

Each instance of the Sun Cluster HA for Oracle data service maintains log files in subdirectories of the /var/opt/SUNWscor directory.

The /var/opt/SUNWscor/oracle_server directory contains log files for the Oracle server.
The /var/opt/SUNWscor/oracle_listener directory contains log files for the Oracle listener.

These files contain information about actions that the Sun Cluster HA for Oracle data service performs. Refer to these files to obtain diagnostic information for troubleshooting your configuration or to monitor the behavior of the Sun Cluster HA for Oracle data service.

Tuning the Sun Cluster HA for Oracle Fault Monitors

Fault monitoring for the Sun Cluster HA for Oracle data service is provided by the following fault monitors:

The Oracle server fault monitor
The Oracle listener fault monitor

Each fault monitor is contained in a resource whose resource type is shown in the following table.

Table 2 Resource Types for Sun Cluster HA for Oracle Fault Monitors


Fault Monitor	Resource Type
Oracle server	`SUNW.oracle_server`
Oracle listener	`SUNW.oracle_listener`

System properties and extension properties of these resources control the behavior of the fault monitors. The default values of these properties determine the preset behavior of the fault monitors. The preset behavior should be suitable for most Sun Cluster installations. Therefore, you should tune the Sun Cluster HA for Oracle fault monitors only if you need to modify this preset behavior.

Tuning the Sun Cluster HA for Oracle fault monitors involves the following tasks:

Setting the interval between fault monitor probes
Setting the timeout for fault monitor probes
Defining the criteria for persistent faults
Specifying the failover behavior of a resource

For more information, see Tuning Fault Monitors for Sun Cluster Data Services in Sun Cluster Data Services Planning and Administration Guide for Solaris OS. Information about the Sun Cluster HA for Oracle fault monitors that you need to perform these tasks is provided in the subsections that follow.

Tune the Sun Cluster HA for Oracle fault monitors when you register and configure Sun Cluster HA for Oracle. For more information, see Registering and Configuring Sun Cluster HA for Oracle.

Operation of the Oracle Server Fault Monitor

The fault monitor for the Oracle server uses a request to the server to query the health of the server.

The server fault monitor is started through pmfadm to make the monitor highly available. If the monitor is killed for any reason, the Process Monitor Facility (PMF) automatically restarts the monitor.

The server fault monitor consists of the following processes.

A main fault monitor process
A database client fault probe

Operation of the Main Fault Monitor

The main fault monitor determines that an operation is successful if the database is online and no errors are returned during the transaction.

Operation of the Database Client Fault Probe

The database client fault probe performs the following operations:

Monitoring the partition for archived redo logs
If the partition is healthy, determining whether the database is operational

The probe uses the timeout value that is set in the resource property Probe_timeout to determine how much time to allocate to successfully probe Oracle.

Operations to Monitor the Partition for Archived Redo Logs

The database client fault probe queries the dynamic performance view v$archive_dest to determine all possible destinations for archived redo logs. For every active destination, the probe determines whether the destination is healthy and has sufficient free space for storing archived redo logs.

If the destination is healthy, the probe determines the amount of free space in the destination's file system. If the amount of free space is less than 10% of the file system's capacity and is less than 20 Mbytes, the probe prints a message to syslog.
If the destination is in ERROR status, the probe prints a message to syslog and disables operations to determine whether the database is operational. The operations remain disabled until the error condition is cleared .

Operations to Determine Whether the Database is Operational

If the partition for archived redo logs is healthy, the database client fault probe queries the dynamic performance view v$sysstat to obtain database performance statistics. Changes to these statistics indicate that the database is operational. If these statistics remain unchanged between consecutive queries, the fault probe performs database transactions to determine if the database is operational. These transactions involve the creation, updating, and dropping of a table in the user table space.

The database client fault probe performs all its transactions as the Oracle user. The ID of this user is specified during the preparation of the nodes or zones as explained in How to Prepare the Nodes.

Actions by the Server Fault Monitor in Response to a Database Transaction Failure

If a database transaction fails, the server fault monitor performs an action that is determined by the error that caused the failure. To change the action that the server fault monitor performs, customize the server fault monitor as explained in Customizing the Sun Cluster HA for Oracle Server Fault Monitor.

If the action requires an external program to be run, the program is run as a separate process in the background.

Possible actions are as follows:

Ignore. The server fault monitor ignores the error.
Stop monitoring. The server fault monitor is stopped without shutting down the database.
Restart. The server fault monitor stops and restarts the entity that is specified by the value of the Restart_type extension property:
- If the Restart_type extension property is set to RESOURCE_RESTART, the server fault monitor restarts the database server resource. By default, the server fault monitor restarts the database server resource.
- If the Restart_type extension property is set to RESOURCE_GROUP_RESTART, the server fault monitor restarts the database server resource group.
Note –
The number of attempts to restart might exceed the value of the Retry_count resource property within the time that the Retry_interval resource property specifies. If this situation occurs, the server fault monitor attempts to switch over the resource group to another node or zone.
Switch over. The server fault monitor switches over the database server resource group to another node or zone. If no nodes or zones are available, the attempt to switch over the resource group fails. If the attempt to switch over the resource group fails, the database server is restarted.

Scanning of Logged Alerts by the Server Fault Monitor

The Oracle software logs alerts in an alert log file. The absolute path of this file is specified by the alert_log_file extension property of the SUNW.oracle_server resource. The server fault monitor scans the alert log file for new alerts at the following times:

When the server fault monitor is started
Each time that the server fault monitor queries the health of the server

If an action is defined for a logged alert that the server fault monitor detects, the server fault monitor performs the action in response to the alert.

Preset actions for logged alerts are listed in Table 2. To change the action that the server fault monitor performs, customize the server fault monitor as explained in Customizing the Sun Cluster HA for Oracle Server Fault Monitor.

Operation of the Oracle Listener Fault Monitor

The Oracle listener fault monitor checks the status of an Oracle listener.

If the listener is running, the Oracle listener fault monitor considers a probe successful. If the fault monitor detects an error, the listener is restarted.

Note –

The listener resource does not provide a mechanism for setting the listener password. If Oracle listener security is enabled, a probe by the listener fault monitor might return Oracle error TNS-01169. Because the listener is able to respond, the listener fault monitor treats the probe as a success. This action does not cause a failure of the listener to remain undetected. A failure of the listener returns a different error, or causes the probe to time out.

The listener probe is started through pmfadm to make the probe highly available. If the probe is killed, PMF automatically restarts the probe.

If a problem occurs with the listener during a probe, the probe tries to restart the listener. The value that is set for the resource property retry_count determines the maximum number of times that the probe attempts the restart. If, after trying for the maximum number of times, the probe is still unsuccessful, the probe stops the fault monitor and does not switch over the resource group.

Obtaining Core Files for Troubleshooting DBMS Timeouts

To facilitate troubleshooting of unexplained DBMS timeouts, you can enable the fault monitor to create a core file when a probe timeout occurs. The contents of the core file relate to the fault monitor process. The fault monitor creates the core file in the / directory. To enable the fault monitor to create a core file, use the coreadm command to enable set-id core dumps. For more information, see the coreadm(1M) man page.

Customizing the Sun Cluster HA for Oracle Server Fault Monitor

Customizing the Sun Cluster HA for Oracle server fault monitor enables you to modify the behavior of the server fault monitor as follows:

Overriding the preset action for an error
Specifying an action for an error for which no action is preset

Caution –

Before you customize the Sun Cluster HA for Oracle server fault monitor, consider the effects of your customizations, especially if you change an action from restart or switch over to ignore or stop monitoring. If errors remain uncorrected for long periods, the errors might cause problems with the database. If you encounter problems with the database after customizing the Sun Cluster HA for Oracle server fault monitor, revert to using the preset actions. Reverting to the preset actions enables you to determine if the problem is caused by your customizations.

Customizing the Sun Cluster HA for Oracle server fault monitor involves the following activities:

Defining custom behavior for errors
Propagating a custom action file to all nodes or zones in a cluster
Specifying the custom action file that a server fault monitor should use

Defining Custom Behavior for Errors

The Sun Cluster HA for Oracle server fault monitor detects the following types of errors:

DBMS errors that occur during a probe of the database by the server fault monitor
Alerts that Oracle logs in the alert log file
Timeouts that result from a failure to receive a response within the time that is set by the Probe_timeout extension property

To define custom behavior for these types of errors, create a custom action file.

Custom Action File Format

A custom action file is a plain text file. The file contains one or more entries that define the custom behavior of the Sun Cluster HA for Oracle server fault monitor. Each entry defines the custom behavior for a single DBMS error, a single timeout error, or several logged alerts. A maximum of 1024 entries is allowed in a custom action file.

Note –

Each entry in a custom action file overrides the preset action for an error, or specifies an action for an error for which no action is preset. Create entries in a custom action file only for the preset actions that you are overriding or for errors for which no action is preset. Do not create entries for actions that you are not changing.

An entry in a custom action file consists of a sequence of keyword-value pairs that are separated by semicolons. Each entry is enclosed in braces.

The format of an entry in a custom action file is as follows:

{
[ERROR_TYPE=DBMS_ERROR|SCAN_LOG|TIMEOUT_ERROR;]
ERROR=error-spec; 
[ACTION=SWITCH|RESTART|STOP|NONE;]
[CONNECTION_STATE=co|di|on|*;]
[NEW_STATE=co|di|on|*;]
[MESSAGE="message-string"]
}

White space may be used between separated keyword-value pairs and between entries to format the file.

The meaning and permitted values of the keywords in a custom action file are as follows:

ERROR_TYPE

Indicates the type of the error that the server fault monitor has detected. The following values are permitted for this keyword:

DBMS_ERROR: Specifies that the error is a DBMS error.
SCAN_LOG: Specifies that the error is an alert that is logged in the alert log file.
TIMEOUT_ERROR: Specifies that the error is a timeout.

The ERROR_TYPE keyword is optional. If you omit this keyword, the error is assumed to be a DBMS error.

ERROR

Identifies the error. The data type and the meaning of error-spec are determined by the value of the ERROR_TYPE keyword as shown in the following table.

`ERROR_TYPE`	Data Type	Meaning
`DBMS_ERROR`	Integer	The error number of a DBMS error that is generated by Oracle
`SCAN_LOG`	Quoted regular expression	A string in an error message that Oracle has logged to the Oracle alert log file
`TIMEOUT_ERROR`	Integer	The number of consecutive timed-out probes since the server fault monitor was last started or restarted

You must specify the ERROR keyword. If you omit this keyword, the entry in the custom action file is ignored.

ACTION

Specifies the action that the server fault monitor is to perform in response to the error. The following values are permitted for this keyword:

NONE: Specifies that the server fault monitor ignores the error.
STOP: Specifies that the server fault monitor is stopped.
RESTART: Specifies that the server fault monitor stops and restarts the entity that is specified by the value of the Restart_type extension property of the SUNW.oracle_server resource.
SWITCH: Specifies that the server fault monitor switches over the database server resource group to another node or zone.

The ACTION keyword is optional. If you omit this keyword, the server fault monitor ignores the error.

CONNECTION_STATE

Specifies the required state of the connection between the database and the server fault monitor when the error is detected. The entry applies only if the connection is in the required state when the error is detected. The following values are permitted for this keyword:

*: Specifies that the entry always applies, regardless of the state of the connection.
co: Specifies that the entry applies only if the server fault monitor is attempting to connect to the database.
on: Specifies that the entry applies only if the server fault monitor is online. The server fault monitor is online if it is connected to the database.
di: Specifies that the entry applies only if the server fault monitor is disconnecting from the database.

The CONNECTION_STATE keyword is optional. If you omit this keyword, the entry always applies, regardless of the state of the connection.

NEW_STATE

Specifies the state of the connection between the database and the server fault monitor that the server fault monitor must attain after the error is detected. The following values are permitted for this keyword:

*: Specifies that the state of the connection must remain unchanged.
co: Specifies that the server fault monitor must disconnect from the database and reconnect immediately to the database.
di: Specifies that the server fault monitor must disconnect from the database. The server fault monitor reconnects when it next probes the database.

The NEW_STATE keyword is optional. If you omit this keyword, the state of the database connection remains unchanged after the error is detected.

MESSAGE

Specifies an additional message that is printed to the resource's log file when this error is detected. The message must be enclosed in double quotes. This message is additional to the standard message that is defined for the error.

The MESSAGE keyword is optional. If you omit this keyword, no additional message is printed to the resource's log file when this error is detected.

Changing the Response to a DBMS Error

The action that the server fault monitor performs in response to each DBMS error is preset as listed in Table 1. To determine whether you need to change the response to a DBMS error, consider the effect of DBMS errors on your database to determine if the preset actions are appropriate. For examples, see the subsections that follow.

To change the response to a DBMS error, create an entry in a custom action file in which the keywords are set as follows:

ERROR_TYPE is set to DBMS_ERROR.
ERROR is set to the error number of the DBMS error.
ACTION is set to the action that you require.

Responding to an Error Whose Effects Are Major

If an error that the server fault monitor ignores affects more than one session, action by the server fault monitor might be required to prevent a loss of service.

For example, no action is preset for Oracle error 4031: unable to allocate num-bytes bytes of shared memory. However, this Oracle error indicates that the shared global area (SGA) has insufficient memory, is badly fragmented, or both states apply. If this error affects only a single session, ignoring the error might be appropriate. However, if this error affects more than one session, consider specifying that the server fault monitor restart the database.

The following example shows an entry in a custom action file for changing the response to a DBMS error to restart.

Example 3 Changing the Response to a DBMS Error to Restart

{
ERROR_TYPE=DBMS_ERROR;
ERROR=4031; 
ACTION=restart;
CONNECTION_STATE=*; 
NEW_STATE=*;
MESSAGE="Insufficient memory in shared pool.";
}

This example shows an entry in a custom action file that overrides the preset action for DBMS error 4031. This entry specifies the following behavior:

In response to DBMS error 4031, the action that the server fault monitor performs is restart.
This entry applies regardless of the state of the connection between the database and the server fault monitor when the error is detected.
The state of the connection between the database and the server fault monitor must remain unchanged after the error is detected.
The following message is printed to the resource's log file when this error is detected:
Insufficient memory in shared pool.

Ignoring an Error Whose Effects Are Minor

If the effects of an error to which the server fault monitor responds are minor, ignoring the error might be less disruptive than responding to the error.

For example, the preset action for Oracle error 4030: out of process memory when trying to allocate num-bytes bytes is restart. This Oracle error indicates that the server fault monitor could not allocate private heap memory. One possible cause of this error is that insufficient memory is available to the operating system. If this error affects more than one session, restarting the database might be appropriate. However, this error might not affect other sessions because these sessions do not require further private memory. In this situation, consider specifying that the server fault monitor ignore the error.

The following example shows an entry in a custom action file for ignoring a DBMS error.

Example 4 Ignoring a DBMS Error

{
ERROR_TYPE=DBMS_ERROR;
ERROR=4030;
ACTION=none;
CONNECTION_STATE=*;
NEW_STATE=*;
MESSAGE="";
}

This example shows an entry in a custom action file that overrides the preset action for DBMS error 4030. This entry specifies the following behavior:

The server fault monitor ignores DBMS error 4030.
This entry applies regardless of the state of the connection between the database and the server fault monitor when the error is detected.
The state of the connection between the database and the server fault monitor must remain unchanged after the error is detected.
No additional message is printed to the resource's log file when this error is detected.

Changing the Response to Logged Alerts

The Oracle software logs alerts in a file that is identified by the alert_log_file extension property. The server fault monitor scans this file and performs actions in response to alerts for which an action is defined.

Logged alerts for which an action is preset are listed in Table 2. Change the response to logged alerts to change the preset action, or to define new alerts to which the server fault monitor responds.

To change the response to logged alerts, create an entry in a custom action file in which the keywords are set as follows:

ERROR_TYPE is set to SCAN_LOG.
ERROR is set to a quoted regular expression that identifies a string in an error message that Oracle has logged to the Oracle alert log file.
ACTION is set to the action that you require.

The server fault monitor processes the entries in a custom action file in the order in which the entries occur. Only the first entry that matches a logged alert is processed. Later entries that match are ignored. If you are using regular expressions to specify actions for several logged alerts, ensure that more specific entries occur before more general entries. Specific entries that occur after general entries might be ignored.

For example, a custom action file might define different actions for errors that are identified by the regular expressions ORA-65 and ORA-6. To ensure that the entry that contains the regular expression ORA-65 is not ignored, ensure that this entry occurs before the entry that contains the regular expression ORA-6.

The following example shows an entry in a custom action file for changing the response to a logged alert.

Example 5 Changing the Response to a Logged Alert

{
ERROR_TYPE=SCAN_LOG;
ERROR="ORA-00600: internal error";
ACTION=RESTART;
}

This example shows an entry in a custom action file that overrides the preset action for logged alerts about internal errors. This entry specifies the following behavior:

In response to logged alerts that contain the text ORA-00600: internal error, the action that the server fault monitor performs is restart.
This entry applies regardless of the state of the connection between the database and the server fault monitor when the error is detected.
The state of the connection between the database and the server fault monitor must remain unchanged after the error is detected.
No additional message is printed to the resource's log file when this error is detected.

Changing the Maximum Number of Consecutive Timed-Out Probes

By default, the server fault monitor restarts the database after the second consecutive timed-out probe. If the database is lightly loaded, two consecutive timed-out probes should be sufficient to indicate that the database is hanging. However, during periods of heavy load, a server fault monitor probe might time out even if the database is functioning correctly. To prevent the server fault monitor from restarting the database unnecessarily, increase the maximum number of consecutive timed-out probes.

Caution –

Increasing the maximum number of consecutive timed-out probes increases the time that is required to detect that the database is hanging.

To change the maximum number of consecutive timed-out probes allowed, create one entry in a custom action file for each consecutive timed-out probe that is allowed except the first timed-out probe.

Note –

You are not required to create an entry for the first timed-out probe. The action that the server fault monitor performs in response to the first timed-out probe is preset.

For the last allowed timed-out probe, create an entry in which the keywords are set as follows:

ERROR_TYPE is set to TIMEOUT_ERROR.
ERROR is set to the maximum number of consecutive timed-out probes that are allowed.
ACTION is set to RESTART.

For each remaining consecutive timed-out probe except the first timed-out probe, create an entry in which the keywords are set as follows:

ERROR_TYPE is set to TIMEOUT_ERROR.
ERROR is set to the sequence number of the timed-out probe. For example, for the second consecutive timed-out probe, set this keyword to 2. For the third consecutive timed-out probe, set this keyword to 3.
ACTION is set to NONE.

Tip –

To facilitate debugging, specify a message that indicates the sequence number of the timed-out probe.

The following example shows the entries in a custom action file for increasing the maximum number of consecutive timed-out probes to five.

Example 6 Changing the Maximum Number of Consecutive Timed-Out Probes

{
ERROR_TYPE=TIMEOUT;
ERROR=2;
ACTION=NONE;
CONNECTION_STATE=*;
NEW_STATE=*;
MESSAGE="Timeout #2 has occurred.";
}

{
ERROR_TYPE=TIMEOUT;
ERROR=3;
ACTION=NONE;
CONNECTION_STATE=*;
NEW_STATE=*;
MESSAGE="Timeout #3 has occurred.";
}

{
ERROR_TYPE=TIMEOUT;
ERROR=4;
ACTION=NONE;
CONNECTION_STATE=*;
NEW_STATE=*;
MESSAGE="Timeout #4 has occurred.";
}

{
ERROR_TYPE=TIMEOUT;
ERROR=5;
ACTION=RESTART;
CONNECTION_STATE=*;
NEW_STATE=*;
MESSAGE="Timeout #5 has occurred. Restarting.";
}

This example shows the entries in a custom action file for increasing the maximum number of consecutive timed-out probes to five. These entries specify the following behavior:

The server fault monitor ignores the second consecutive timed-out probe through the fourth consecutive timed-out probe.
In response to the fifth consecutive timed-out probe, the action that the server fault monitor performs is restart.
The entries apply regardless of the state of the connection between the database and the server fault monitor when the timeout occurs.
The state of the connection between the database and the server fault monitor must remain unchanged after the timeout occurs.
When the second consecutive timed-out probe through the fourth consecutive timed-out probe occurs, a message of the following form is printed to the resource's log file:
Timeout #number has occurred.
When the fifth consecutive timed-out probe occurs, the following message is printed to the resource's log file:
Timeout #5 has occurred. Restarting.

Propagating a Custom Action File to All Nodes in a Cluster

A server fault monitor must behave consistently on all cluster nodes or zones. Therefore, the custom action file that the server fault monitor uses must be identical on all cluster nodes or zones. After creating or modifying a custom action file, ensure that this file is identical on all cluster nodes or zones by propagating the file to all cluster nodes or zones. To propagate the file to all cluster nodes or zones, use the method that is most appropriate for your cluster configuration:

Locating the file on a file system that all nodes or zones share
Locating the file on a highly available local file system
Copying the file to the local file system of each cluster node or zone by using operating system commands such as the rcp(1) command or the rdist(1) command

Specifying the Custom Action File That a Server Fault Monitor Should Use

To apply customized actions to a server fault monitor, you must specify the custom action file that the fault monitor should use. Customized actions are applied to a server fault monitor when the server fault monitor reads a custom action file. A server fault monitor reads a custom action file when the you specify the file.

Specifying a custom action file also validates the file. If the file contains syntax errors, an error message is displayed. Therefore, after modifying a custom action file, specify the file again to validate the file.

Caution –

If syntax errors in a modified custom action file are detected, correct the errors before the fault monitor is restarted. If the syntax errors remain uncorrected when the fault monitor is restarted, the fault monitor reads the erroneous file, ignoring entries that occur after the first syntax error.

How to Specify the Custom Action File That a Server Fault Monitor Should Use

On a cluster node, become superuser or assume a role that provides solaris.cluster.modify RBAC authorization.

Set the Custom_action_file extension property of the SUNW.oracle_server resource.

Set this property to the absolute path of the custom action file.
# clresource set -p custom_action_file=filepath server-resource
-p custom_action_file=filepath

Specifies the absolute path of the custom action file.

server-resource

Specifies the SUNW.oracle_server resource.

Upgrading Sun Cluster HA for Oracle Resource Types

The resource types for the Sun Cluster HA for Oracle data service are as follows:

SUNW.oracle_listener, which represents an Oracle listener
SUNW.oracle_server, which represents an Oracle server

Upgrade these resource types if you are upgrading from an earlier version of Sun Cluster HA for Oracle.

For general instructions that explain how to upgrade a resource type, see Upgrading a Resource Type in Sun Cluster Data Services Planning and Administration Guide for Solaris OS.

Upgrading the `SUNW.oracle_listener` Resource Type

The information that you require to complete the upgrade of the SUNW.oracle_listener resource type is provided in the subsections that follow.

Information for Registering the New Resource Type Version

The relationship between the version of the SUNW.oracle_listener resource type and the release of Sun Cluster data services is shown in the following table. The release of Sun Cluster data services indicates the release in which the version of the resource type was introduced. The table also summarizes the changes that were introduced in each new version.

`SUNW.oracle_listener` Resource Type Version	Sun Cluster Data Services Release	Summary of Changes
1	1.0	Not applicable
3.1	3.1 5/03	Directives to enable upgrades of this resource type introduced
4	3.1 4/04	`Probe_timeout` extension property introduced
5	3.1 8/05	Default value of the `Probe_timeout` extension property increased to 180 seconds

To determine the version of the resource type that is registered, use one command from the following list:

clresourcetype list
clresourcetype show

The resource type registration (RTR) file for this resource type is /opt/SUNWscor/oracle_listener/etc/SUNW.oracle_listener.

Information for Migrating Existing Instances of the Resource Type

The information that you require to edit each instance of the SUNW.oracle_listener resource type is as follows:

You can perform the migration at any time.
If you need to use the features of the SUNW.oracle_listener resource type that were introduced in version 3.1 4/04, the required value of the Type_version property is 4.
If you need to use the features of the SUNW.oracle_listener resource type that were introduced in version 3.1 8/05, the required value of the Type_version property is 5.
If you need to specify the timeout value in seconds that the fault monitor uses to probe an Oracle listener, set the Probe_timeout extension property. For more information, see SUNW.oracle_listener Extension Properties.

Note –

If you are using version 4 of the SUNW.oracle_listener resource type, upgrade to version 4 only if you require the new default values. If the default values in version 4 are satisfactory, you do not need to upgrade.

The following example shows a command for editing an instance of the SUNW.oracle_listener resource type.

Example 7 Editing an Instance of the `SUNW.oracle_listener` Resource Type

# clresource set  -p Type_version=4 \
  -p probe_timeout=60 oracle-lrs

This command edits a SUNW.oracle_listener resource as follows:

The SUNW.oracle_listener resource is named oracle-lrs.
The Type_version property of this resource is set to 4.
The timeout value in seconds that the fault monitor uses to probe an Oracle listener is set to 60 seconds.

Upgrading the `SUNW.oracle_server` Resource Type

The information that you require to complete the upgrade of the SUNW.oracle_server resource type is provided in the subsections that follow.

Information for Registering the New Resource Type Version

The relationship between the version of the SUNW.oracle_server resource type and the release of Sun Cluster data services is shown in the following table. The release of Sun Cluster data services indicates the release in which the version of the resource type was introduced. The table also summarizes the changes that were introduced in each new version.

`SUNW.oracle_server` Resource Type Version	Sun Cluster Data Services Release	Summary of Changes
1	1.0	Not applicable
1.1	3.0 5/02 asynchronous release	Directives to enable upgrades of this resource type introduced `Auto_End_Bkp` extension property introduced
3.1	3.1 5/03	`Restart_type` extension property introduced
4	3.1 10/03	`Custom_action_file` extension property introduced
5	3.1 8/05	Default values of extension properties changed as follows: Default value of `Probe_timeout` extension property increased to 300 seconds Default value of `Restart_type` extension property changed to `RESOURCE_RESTART`
6	3.2	Support for standby instances `Dataguard_role` extension property introduced. The possible values are as follows: `NONE` `PRIMARY` `STANDBY` `IN_TRANSITION` `Standby_mode` extension property introduced. The possible values are as follows: `LOGICAL` `PHYSICAL`

To determine the version of the resource type that is registered, use one command from the following list:

clresourcetype list
clresourcetype show

The resource type registration (RTR) file for this resource type is /opt/SUNWscor/oracle_server/etc/SUNW.oracle_server.

Information for Migrating Existing Instances of the Resource Type

The information that you require to edit each instance of the SUNW.oracle_server resource type is as follows:

You can perform the migration at any time.
If you need to use the features of the SUNW.oracle_server resource type that were introduced in version 3.1 10/03, the required value of the Type_version property is 4.
If you need to use the features of the SUNW.oracle_server resource type that were introduced in version 3.1 8/05, the required value of the Type_version property is 5.
If you customized the behavior of the server fault monitor, set the Custom_action_file extension property. For more information, see Customizing the Sun Cluster HA for Oracle Server Fault Monitor.

Note –

If you are using version 4 of the SUNW.oracle_server resource type, upgrade to version 4 only if you require the new default values. If the default values in version 4 are satisfactory, you do not need to upgrade.

The following example shows a command for editing an instance of the SUNW.oracle_server resource type.

Example 8 Editing an Instance of the `SUNW.oracle_server` Resource Type

# clresource set  -p Type_version=4 \
  -p custom_action_file=/opt/SUNWscor/oracle_server/etc/srv_mon_cust_actions \ 
oracle-srs

This command edits a SUNW.oracle_server resource as follows:

The SUNW.oracle_server resource is named oracle-srs.
The Type_version property of this resource is set to 4.
Custom behavior for the fault monitor of this resource is specified in the file /opt/SUNWscor/oracle_server/etc/srv_mon_cust_actions.

Changing the Role of a DataGuard Instance

Database role failover or switchover is possible between an Oracle primary database and an Oracle standby database. When you use Oracle commands to change the role of DataGuard instances, the changes are not propagated to the Sun Cluster resources that represent these instances. Therefore, you must also use Sun Cluster commands to change extension properties of these resources to ensure that database instances are started in the correct role.

How to Change the Role of a DataGuard Instance

Prevent Sun Cluster from starting the instance in an incorrect role.

If a node or zone fails while you are changing the role of a DataGuard instance, Sun Cluster might restart the instance in an incorrect role. To prevent this possibility, change the Dataguard_role extension property of the Oracle server resource that represents the instance to IN_TRANSITION.
# clresource set -p Dataguard_role=IN_TRANSITION server-rs

Perform the required operations on the Oracle database to convert the database to a new role.

Change the following extension properties of the Oracle server resource that represents the instance to reflect the new role of the instance:
- Dataguard_role
- Standby_mode
The required combination of Dataguard_role and Standby_mode depends on the change of role, as follows:
- To change from a primary database to a physical standby database, run the following command:
  # clresource set -p Dataguard_role=STANDBY -p Standby_mode=PHYSICAL server-rs
- To change from a primary database to a logical standby database, run the following command:
  # clresource set -p Dataguard_role=STANDBY \ -p Standby_mode=LOGICAL server-rs
- To change from a standby database to a primary database, run the following command:
  # clresource set -p Dataguard_role=PRIMARY server-rs

Installing and Configuring Sun Cluster HA for Oracle

Overview of the Installation and Configuration Process for Sun Cluster HA for Oracle

Planning the Sun Cluster HA for Oracle Installation and Configuration

Configuration Requirements

Configuration Planning Questions

Preparing the Nodes and Disks

How to Prepare the Nodes

How to Configure Oracle Database Access Using Solaris Volume Manager

How to Configure Oracle Database Access Using Veritas Volume Manager

Installing the Oracle Software

How to Install the Oracle Software

How to Set the Oracle Kernel Parameters

Verifying the Oracle Installation and Configuration

How to Verify the Oracle Installation

Next Steps

Creating an Oracle Database

How to Create a Primary Oracle Database

Next Steps

Setting Up Oracle Database Permissions

How to Set Up Oracle Database Permissions

Next Steps

Installing the Sun Cluster HA for Oracle Packages

How to Install the Sun Cluster HA for Oracle Packages

Before You Begin

Next Steps

Registering and Configuring Sun Cluster HA for Oracle

Tools for Registering and Configuring Sun Cluster HA for Oracle

Setting Sun Cluster HA for Oracle Extension Properties

How to Register and Configure Sun Cluster HA for Oracle by Using the clsetup Utility

Before You Begin

How to Register and Configure Sun Cluster HA for Oracle by Using Sun Cluster Maintenance commands

Before You Begin

Example 1 Registering Sun Cluster HA for Oracle to Run in the Global Zone

Example 2 Registering Sun Cluster HA for Oracle to Run in the Non-Global Zone

Where to Go From Here

Verifying the Sun Cluster HA for Oracle Installation

How to Verify the Sun Cluster HA for Oracle Installation

Oracle Clients

Location of Sun Cluster HA for Oracle Log Files

Tuning the Sun Cluster HA for Oracle Fault Monitors

Operation of the Oracle Server Fault Monitor

Operation of the Main Fault Monitor

Operation of the Database Client Fault Probe

Operations to Monitor the Partition for Archived Redo Logs

Operations to Determine Whether the Database is Operational

Actions by the Server Fault Monitor in Response to a Database Transaction Failure

Scanning of Logged Alerts by the Server Fault Monitor

Operation of the Oracle Listener Fault Monitor

Obtaining Core Files for Troubleshooting DBMS Timeouts

Customizing the Sun Cluster HA for Oracle Server Fault Monitor

Defining Custom Behavior for Errors

Custom Action File Format

Changing the Response to a DBMS Error

Responding to an Error Whose Effects Are Major

Example 3 Changing the Response to a DBMS Error to Restart

Ignoring an Error Whose Effects Are Minor

Example 4 Ignoring a DBMS Error

Changing the Response to Logged Alerts

Example 5 Changing the Response to a Logged Alert

Changing the Maximum Number of Consecutive Timed-Out Probes

Example 6 Changing the Maximum Number of Consecutive Timed-Out Probes

Propagating a Custom Action File to All Nodes in a Cluster

Specifying the Custom Action File That a Server Fault Monitor Should Use

How to Specify the Custom Action File That a Server Fault Monitor Should Use

Upgrading Sun Cluster HA for Oracle Resource Types

Upgrading the SUNW.oracle_listener Resource Type

Information for Registering the New Resource Type Version

Information for Migrating Existing Instances of the Resource Type

Example 7 Editing an Instance of the SUNW.oracle_listener Resource Type

Upgrading the SUNW.oracle_server Resource Type

Information for Registering the New Resource Type Version

Information for Migrating Existing Instances of the Resource Type

Example 8 Editing an Instance of the SUNW.oracle_server Resource Type

Changing the Role of a DataGuard Instance

How to Change the Role of a DataGuard Instance

How to Register and Configure Sun Cluster HA for Oracle by Using the `clsetup` Utility

Upgrading the `SUNW.oracle_listener` Resource Type

Example 7 Editing an Instance of the `SUNW.oracle_listener` Resource Type

Upgrading the `SUNW.oracle_server` Resource Type

Example 8 Editing an Instance of the `SUNW.oracle_server` Resource Type