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

part 'Creation of Replication Instance' is required. The split of the Central Instance is then already
effective and an [A]SCS instance was created during installation.
In this case it is sufficient to ensure that the [A]SCS startup profile does not use local Restart
for the enqueue process and that the instance profile contains recommended replication parameter
settings, for example:
enque/server/internal_replication = true
enque/server/replication = true
enque/server/threadcount = 1
enque/enrep/keepalive_count = 0
enque/process_location = local
enque/table_size = 4096
ipc/shm_psize_34 = 0
Using Replicated Enqueue heavily changes the SAP instance landscape and increases the resource
demand: two additional SAP instances will be generated as the outcome of the splitting procedure.
There is a requirement for at least one additional unique SAP System ID. Unique means, that the
ID is not in use by any other SAP instance of the cluster. There is also a requirement for one or two
additional shared LUNs on the SAN and one or two additional virtual IP addresses for each subnet.
The LUNs need to have the size that is required for a SAP Instance directory of the targeted kernel
release.
Splitting an ABAP Central Instance
The SPOFs of the DVEBMGS<INSTNR> instance will be isolated in a new instance called ABAP
System Central Services Instance ASCS<INSTNR>. This instance will replace DVEBMGS<INSTNR>
for the ci package type. The remaining parts of the Central Instance can be configured as Dialog
Instance D<INSTNR_2>. The ASCS Instance should only be started and stopped with the cluster
package startup and halt commands instead of using manual shell operations.
NOTE: The Dialog Instance D<INSTNR_2> that results from the conversion also represents one
or more Single Points of Failure for many scenarios. In these cases, D<INSTNR_2> should also be
clustered with SGeSAP. It is not even unusual to combine ASCS<INSTNR> and D<INSTNR_2>
in a single SGeSAP package. It makes sense, even though the resulting package contains the same
components like a traditional package for DVEBMGS<INSTNR> would. Seamless failover with
Replicated Enqueue cannot be achieved without splitting up DVEBMGS<INSTNR> into two instances.
Logon as root to the server where the Central Instance DVEBMGS<INSTNR> was installed.
Replicated Enqueue Conversion: RE010
Create a new mountpoint:
su - <sid>adm
mkdir/usr/sap/<SID>/ASCS<INSTNR>
Replicated Enqueue Conversion: RE020
A volume group needs to be created for the ASCS instance .
The physical device(s) should be created as LUN(s) on shared storage. Storage connectivity is
required from all nodes of the cluster that should run the ASCS. For the volume group, one logical
volume should get configured. For the required size, refer to the capacity consumption of
/usr/sap/<SID>/DVEBMGS<INSTNR>. This should provide a conservative upper limit that
leaves reasonable headroom.
Mount the new logical volume to the mountpoint created in RE010.
Replicated Enqueue Conversion: RE030
Create instance subdirectories in the mounted logical volume .
At a later time, these will be switched between the cluster nodes.
SAP Preparation 51