WAIT_OWN_AS=2

if the package should also wait for all application servers to come up successfully. You have to use this value if you want to prevent the integration from temporarily opening a new process group for each application server during startup.

WAIT_OWN_AS=0

can significantly speed up the package start and stop, especially if Windows NT application servers are used. Use this value only if you have carefully tested and verified that timing issues will not occur.

Optional Step: OS710

Specify SAPOSCOL_STOP=1 if saposcol should be stopped together with each instance that is stopped.

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 ERS 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

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.

Control the handling of resources.

Prior to any instance startup the SGeSAP 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 SGeSAP 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 HP-UX 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 HP-UX 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. 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 HP-UX. 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 /etc/cmcluster/<SID> there is a file called customer.functions that provides a couple of predefined function hooks. They allow the specification of individual startup or runtime steps at certain phases

76 Step-by-Step Cluster Conversion

Page 76
Image 76
HP Serviceguard Extension for SAP (SGeSAP) manual Optional Parameters and Customizable Functions, WAITOWNAS=2, WAITOWNAS=0