Managing Serviceguard Extension for SAP on Linux (IA64 Integrity and x86_64), April 2009

The collector will only be stopped if there is no instance of an SAP system running on the host. Specify
SAPOSCOL_START=1 to start the saposcol even with packages that don't use the implicit startup mechanism
that comes with SAP instance startup, e.g. database-only packages or packages that only have a SCS, ASCS
or AREP instance.
Optional Step: OS720
If several packages start on a single node after a failover, it is likely that some packages start up faster than
others on which they might depend.
To allow synchronization in this case, there is a loop implemented that polls the missing resources regularly.
After the first poll, the script will wait 5 seconds before initiating the next polling attempt. The polling interval
is doubled after each attempt with an upper limit of 30 seconds. Polling continues until the resource becomes
available or up to a maximum of DELAY_INTERVALS polling attempts.
Optional Step: OS730
On Linux, a shared memory shortage can occur if you install more than one instance on a host.
Control the handling of resources.
Prior to any instance startup the Serviceguard Extension for SAP on Linux tries to free up unused or unimportant
resources to make the startup more likely to succeed. A database package only frees up database related
resources, a Central Instance package only removes IPCs belonging to SAP administrators.
The following list summarizes how the behavior of Serviceguard Extension for SAP on Linux is affected by
changing the CLEANUP_POLICY parameter:
▲ lazy - no action, no cleanup of resources
• normal - removes unused resources belonging to the own system
• strict - uses Linux commands to free up all semaphores and shared memory segments that belong to
any SAP Instance of any SAP system on the host if the Instance is to be started soon. It uses Linux to
free up all semaphores and shared memory segments that belong to any database if the SAP database
is to be started soon.
NOTE: Do not use the strict policy unless it is critical that you do. 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. A strict policy frees up more of its own shared memory segments than the normal policy does.
For the cleanup of resources cleanipc is used which is an SAP tool to free up the IPC resources of specific
SAP Instances. It is used to free up resources of an Instance that is to be started soon on Linux. This prevents
shared memory issues caused by the remains of a prior crash of the Instance. Accordingly, an obsolete
ORACLE SGA is also removed if a database crash occurred.
Optional Parameters and Customizable Functions
In ${SGCONF}/<SID> there is a file called customer.functions that provides a set of predefined
function hooks. They allow the specification of individual startup or runtime steps at certain phases of the
package script execution. Any customer specific changes or customer additional scripts must be added in
customer.functions and not in sap.functions. Therefore it is not necessary and also not supported
to change the sap.functions.
In the following there is a summary of the function hooks in chronological order:
Table 3-2 Optional Parameters and Customizable Functions List
Description:Command:
additional startup steps on database host after all low level resources are made available
after the system has been cleaned up for db start before start of database instance
start_addons_predb
additional startup steps on database host after start of the database instancestart_addons_postdb
additional startup steps on Central Instance host after start of the database instancestart_addons_preci
90 Step-by-Step Cluster Conversion