Managing Serviceguard Extension for SAP Version B.05.10, December 2012

Batch jobs can be scheduled to run on a particular instance. Generally speaking, it is better not
to specify a destination host at all. Sticking to this rule, the batch scheduler chooses a batch server
that is available at the start time of the batch job. However, if you want to specify a destination
host, specify the batch server running on the highly available Central Instance. The application
server name and the hostname (retrieved from the Message Server) are stored in the batch control
tables TBTCO,TBTCS,.... In case the batch job is ready to run, the application server name is used
to start it. Therefore, when using the relocatable name to build the Application Server name for
the instance, you do not need to change batch jobs that are tied to it after a switchover. This is
true even if the hostname, that is also stored in the above tables, differs.
Plan to use saplogon to application server groups instead of saptemu/sapgui to individual
application servers. When logging on to an application server group with two or more application
servers, the SAP user does not need a different login procedure if one of the application servers
of the group fails. Also, using login groups, provides workload balancing between application
servers, too.
Within the CCMS you can define operation modes for SAP instances. An operation mode defines
a resource configuration. It can be used to determine which instances are started and stopped and
how the individual services are allocated for each instance in the configuration. An instance
definition for a particular operation mode consists of the number and types of Work processes as
well as Start and Instance Profiles. When defining an instance for an operation mode, you need
to enter the hostname and the system number of the application server. By using relocatable names
to fill in the hostname field, the instance will be working under control of the CCMS after a failover
without a change.
NOTE: If an instance is running on the standby node in normal operation and is stopped during
the switchover, only configure the update service on a node for Application Services running on
the same node. As a result, the remaining servers, running on different nodes, are not affected by
the outage of the update server. However, if the update server is configured to be responsible for
application servers running on different nodes, any failure of the update server leads to subsequent
outages at these nodes. Configure the update server on a clustered instance. Using local update
servers should only be considered, if performance issues require it.
Ongoing verification of package failover capabilities
The SGeSAP functionality includes SAP specific verifications that test the node-local operating
environment configurations. These checks detect the incorrect local settings that might prevent a
successful SAP failover. The routines are executed as part of cmcheckconf(1m) and
cmapplyconf(1m) commands run on SGeSAP package configurations. The cmcheckconf -P
<`currently_applied_pkg_config_file`> command can be scheduled at regular intervals
to verify the failover capabilities of already running SGeSAP packages. These tests are executed
on the current node as well as on all reachable, configured failover nodes of the SGeSAP package.
The resulting logs will be merged.
A cmcheckconf(1m) run command performs a complete test only if an SGeSAP package is up
and running. In this case all file systems are accessible, and allows a complete verification. If the
SGeSAP package is halted, only a subset of the checks can be performed.
NOTE: The successful execution of cmcheckconf(1m) command does not guarantee a successful
failover. The currently available functionality cannot replace any regular failover test mechanism.
These checks complement existing tests and is useful to detect issues timely. Usually, these issues
occur at a time when failover testing, that includes downtime can not be performed.
If required, the execution of SGeSAP cluster verification as part of the cmcheckconf(1m) and
cmapplyconf(1m) command routines can be deactivated. The existence of a file called /var/
adm/cmcluster/debug_sapverify will skip SGeSAP cluster verification for all packages on
that cluster node. The existence of a file /var/adm/cmcluster/debug_sapverify_${sgpkg}
skips verification only for the SGeSAP package ${sgpkg} on that cluster node. Generic and
26 SGeSAP Cluster Administration