User's Guide

is not delivering installation routines that install Replicated Enqueue configurations for these releases, so the
manual conversion steps become necessary. The 4.6D kernel does require some kernel executables of the
6.40 kernel to be added.
If the SAP installation was done for Netweaver 2004 Java-only, Netweaver 2004s, or a newer release as
documented in section 'SAP Installation Considerations', only the second part 'Creation of Replication
Instance' is required. The split of the Central Instance is then already effective and a [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, eg:
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 during 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 then be configured as Dialog Instance D<INSTNR_2>.
The ASCS Instance should then 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> andD<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 can not be achieved without
splitting up DVEBMGS<INSTNR> into two instances.
Logon as root to the server on which 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.
SAP Preparation 39