Sun Cluster Data Service for MaxDB Guide for Solaris OS

Tuning the Sun Cluster HA for MaxDB Fault Monitors

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

The MaxDB fault monitor
The SAP xserver fault monitor

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

Table 3 Resource Types for Sun Cluster HA for MaxDB Fault Monitors


Fault Monitor	Resource Type
MaxDB	`SUNW.sapdb`
SAP xserver	`SUNW.sap_xserver`

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 MaxDB fault monitors only if you need to modify this preset behavior.

Tuning the Sun Cluster HA for MaxDB 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 MaxDB fault monitors that you need to perform these tasks is provided in the subsections that follow.

Sun Cluster HA for MaxDB also enables you to control how the fault monitor responds if the MaxDB parent kernel process is not running. For more information, see Forcing the MaxDB Database Instance to Be Restarted if the Parent Kernel Process Is Terminated.

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

Factors That Affect the Interval Between Fault Monitor Probes

To determine whether SAP xserver and the MaxDB database instance are operating correctly, the Sun Cluster HA for MaxDB fault monitors probe these resources periodically. The optimum interval between fault monitor probes depends on the time that is required to respond to a fault in a resource. This time depends on how the complexity of the resource affects the time that is required for operations such as restarting the resource.

For example, SAP xserver is a much simpler resource and can be restarted much quicker than MaxDB. Therefore, the optimum interval between fault monitor probes of SAP xserver is shorter than the optimum interval between probes of MaxDB.

Operations by the Sun Cluster HA for MaxDB Fault Monitors During a Probe

The optimum timeout for fault monitor probes depends on the operations that a fault monitor performs to probe the resource.

Operations by the MaxDB Fault Monitor During a Probe

During a probe, the MaxDB fault monitor performs the following operations:

The MaxDB fault monitor determines whether the MaxDB database instance is online.
If the MaxDB database instance is online, the MaxDB fault monitor determines whether the parent kernel process of the MaxDB database instance is running. You can control how the fault monitor responds if the parent kernel process is not running. For more information, see Forcing the MaxDB Database Instance to Be Restarted if the Parent Kernel Process Is Terminated.
The MaxDB fault monitor determines whether SAP xserver is available. This fault monitoring supplements the fault monitoring that the SAP xserver fault monitor provides.

Operations by the SAP xserver Fault Monitor During a Probe

During a probe, the SAP xserver fault monitor determines whether SAP xserver is available.

Faults Detected by the Sun Cluster HA for MaxDB Fault Monitors

Faults that each Sun Cluster HA for MaxDB fault monitor detects are described in the subsections that follow.

Faults Detected by the MaxDB Fault Monitor

The MaxDB fault monitor detects the following faults in MaxDB:

A status of the MaxDB database instance that is not ONLINE, for example, OFFLINE or ADMIN
Unexpected termination of the parent kernel process of the MaxDB database instance

The MaxDB fault monitor also detects the unavailability of SAP xserver. This fault monitoring supplements the fault monitoring that the SAP xserver fault monitor provides.

Note –

If the MaxDB fault monitor detects that SAP xserver is unavailable twice within the retry interval, the MaxDB fault monitor restarts MaxDB. By restarting MaxDB, the fault monitor ensures that the MaxDB database fails over to another node when SAP xserver is persistently unavailable.

Faults Detected by the SAP xserver Fault Monitor

The SAP xserver fault monitor detects following faults:

Unavailability of SAP xserver. Unavailability of SAP xserver is also detected by the MaxDB fault monitor.
Persistent system errors. A persistent system error is a system error that occurs four times within the retry interval. If a persistent system error occurs, the fault monitor restarts SAP xserver.

Recovery Actions in Response to Detected Faults

To minimize the disruption that transient faults in a resource cause, a fault monitor restarts the resource in response to such faults. For persistent faults, more disruptive action than restarting the resource is required:

For the MaxDB resource, the fault monitor fails over the resource to another node. The MaxDB resource is a failover resource.
For the SAP xserver resource, the fault monitor takes the resource offline. The SAP xserver is a scalable resource.

Forcing the MaxDB Database Instance to Be Restarted if the Parent Kernel Process Is Terminated

By default, unexpected termination of the parent kernel process does not cause the MaxDB fault monitor to restart the MaxDB database instance. The MaxDB database instance can continue to function without the parent kernel process. Restarting the MaxDB database instance in this situation might cause unnecessary unavailability of the MaxDB database instance. Therefore, you should force the MaxDB database instance to be restarted only if you require a feature that the parent kernel process provides. An example of such a feature is maintaining the integrity of the log history.

To force the MaxDB database instance to be restarted if the parent kernel process is terminated, set the Restart_if_Parent_Terminated extension property of the SUNW.sapdb resource to True.