Managing Serviceguard Extension for SAP Version A.06.00 for Linux, December 2012

Post SAP installation tasks and final node synchronization (Phase 3a)
After the SAP installation has completed in Phase 2, some SAP configuration values may have to
be changed for running the instance in the cluster.
Additionally, each cluster node (except the primary where the SAP installation runs) must be updated
to reflect the configuration changes from the primary.
Complete the following tasks for Phase 3 before the SGeSAP package is finalized:
• Configuration settings of the SAP installation:
Program start entries in the SAP profiles◦
◦ MaxDB xserver autostart
◦ Oracle listener names
◦ Hostname references in DB configuration files
• Review SAP parameters, which can conflict with SGeSAP.
• At the Operating System (OS) level, synchronize the SAP installation changes on the primary
node with all the secondary nodes in the cluster.
◦ User and groups related information for the SAP SID and DB administrator.
◦ Update login scripts containing virtual hostnames.
◦ Duplicate file systems identified as “local” to the secondary nodes. For more information
on “local”, see chapter 4 “SAP cluster storage layout planning” (page 30).
◦ DB related synchronization for MaxDB and Oracle
• Adjust system wide configuration parameters to meet SAP requirements.
NOTE: Before starting with any Phase 3 configurations steps, ensure all the “base packages”
are up and running. For example, ensure that all the relevant file systems are mounted. This
is important for the Serviceguard Manager auto-discovery tool to work properly and provide
pre-filled fields of the currently installed SAP configuration.
SAP post installation modifications and checks
HP recommends that you modify some of the settings generated by the SAP installation to avoid
conflicting behavior when run together with SGeSAP.
Disable SCS enqueue restarts, if SGeSAP ERS is also configured
Disable SCS enqueue restarts if SCS is installed with the Restart_Program parameter enabled
for the enqueue process.
This configuration automatically restarts the enqueue on the current node, destroying the replicated
enqueue lock table when the ERS reconnects to the restarted SCS instance. The desired behavior
is that the SCS package failover to the node, where the ERS package with the replicated lock table
is running and recover the replicated enqueue locks from there.
In [A]SCS profile the line with Restart (number might vary)
Restart_Program_01 = local $(_EN)
has to be changed to Start.
Start_Program_01 = local $(_EN)
Post SAP installation tasks and final node synchronization (Phase 3a) 59