Installing and Configuring HA for Oracle
Overview of the Installation and Configuration Process for HA for Oracle
Planning the HA for Oracle Installation and Configuration
Configuration Planning Questions
How to Configure the Oracle Database Access Using Solaris Volume Manager
How to Configure the Oracle Database Access Using Veritas Volume Manager
How to Configure the Oracle Database Access Using Oracle ASM
How to Install the Oracle ASM Software
How to Verify the Oracle ASM Software Installation
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
How to Create a Primary Oracle Database
Setting Up Oracle Database Permissions
How to Set Up Oracle Database Permissions
Installing the HA for Oracle Packages
How to Install the HA for Oracle Packages
Registering and Configuring HA for Oracle
Tools for Registering and Configuring HA for Oracle
Setting HA for Oracle Extension Properties
How to Register and Configure HA for Oracle by Using the clsetup Utility
Verifying the HA for Oracle Installation
How to Verify the HA for Oracle Installation
Location of HA for Oracle Log Files
Tuning the 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
Customizing the HA for Oracle Server Fault Monitor
Defining Custom Behavior for Errors
Changing the Response to a DBMS Error
Responding to an Error Whose Effects Are Major
Ignoring an Error Whose Effects Are Minor
Changing the Response to Logged Alerts
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 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
Upgrading the SUNW.oracle_server Resource Type
Information for Registering the New Resource Type Version
Information for Migrating Existing Instances of the Resource Type
Changing the Role of an Oracle Data Guard Instance
How to Change the Role of an Oracle Data Guard Instance
A. HA for Oracle Extension Properties
B. Preset Actions for DBMS Errors and Logged Alerts
Fault monitoring for the 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 4 Resource Types for HA for Oracle Fault Monitors
|
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 Oracle Solaris Cluster installations. Therefore, you should tune the HA for Oracle fault monitors only if you need to modify this preset behavior.
Tuning the 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 Oracle Solaris Cluster Data Services in Oracle Solaris Cluster Data Services Planning and Administration Guide. Information about the HA for Oracle fault monitors that you need to perform these tasks is provided in the subsections that follow.
Tune the HA for Oracle fault monitors when you register and configure HA for Oracle. For more information, see Registering and Configuring HA for Oracle.
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
This section contains the following information about the server 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.
The database client fault probe performs the following operations:
Monitoring the partition for archived redo logs. See Operations to Monitor the Partition for Archived Redo Logs.
If the partition is healthy, determining whether the database is operational. See Operations to Determine 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.
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 .
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.
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 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.
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 HA for Oracle Server 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.
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.