Managing Serviceguard Extension for SAP Version B.05.10, September 2010

The following list summarizes how the behavior of SGeSAP is affected with different settings of
the cleanup_policy parameter:
• lazy—no action, no cleanup of resources.
• normal—removes orphaned resources as reported by SAP tools for the SAP system that is
specified in sap_system. An obsolete ORACLE SGA is also removed if a database crash
occurred.
• strict—uses HP-UX commands to free up system resources that belong to any SAP Instance
of any SAP system on the host if the Instance is to be started soon.
NOTE: Do not use the strict policy unless it is required. Be aware that the strict option can crash
running instances of different SAP systems on the backup host. Use this value only if you have
a productive system that is much more important than any other SAP system you have. In this
case, a switchover of the productive system is more robust, but additional SAP systems will
crash.
You can also use strict policy, if your SAP system is the only one running at the site and you are
low on memory. Strict policy frees up more of its own shared memory segments than the normal
policy does.
Optional Step: OS423
It is possible to influence the system cleanup behavior of SGeSAP.
Many SGeSAP package activities depend on system resources that are provided via mechanisms
that are not directly handled by the package. If these resources are not available, a package
operation could fail. Sometimes the resources are just temporarily unavailable and the package
activity would succeed if delayed long enough. To allow that kind of synchronization, SGeSAP
enters loops that poll missing resources regularly and delays or retries activities that depend on
these resources. The package activity continues after the resource becomes available again or
fails after a maximum of retry_count attempts to successfully finish the activity.
The default for the parameter is set to 5. It can be raised on demand, if the package logs indicate
racing conditions with timing issues.
Subsection for the Oracle database component: OR425
Parameters that can be set to handle an Oracle single-instance database as part of a package
with the sgesap/dbinstance or sgesap/oracledb module.
The package parameter db_vendor defines the underlying RDBMS database technology that
is to be used with the SAP application. It is preset to oracle in sgesap/oracledb, but should
otherwise be manually set to oracle. It is still optional to specify this parameter, but either
db_vendor or db_system needs to be set in order to include the database in the failover package.
db_system determines the name of the database (schema) for SAP. Usually it is a three letter
name, similar to a sap_system value (SID). If the value is not specified, but db_vendor has
been set, a database with default db_system=sap_system is assumed (SAP’s installation
default), if sap_system is specified elsewhere in the package configuration.
Optionally, listener_name can be set if the Oracle listener is defined on a name different from
the default value LISTENER.
Optionally, listener_password can be set if a password for the Oracle listener process is
configured. The root user and any user with a defined Serviceguard access role (full admin,
package admin or monitor) will be able to read this value.
sgesap/dbinstance can be used for databases of SAP JAVA-only, ABAP-only or dual stack
instances. The module will detect all available SAP tools to handle the database and use them if
possible. If no SAP tools are there or the SAP tools fail to work, a fallback is implemented to
handle the database with generic tools of the database vendor.
Subsection for the MAXDB database component: SD426
72 Step-by-Step Cluster Conversion