Managing an Enqueue Replication Server (ERS)

In older SAP releases, AS ABAP-based SAP systems were installed with an enqueue as work process of the Primary Application Server, also called Central Instance. Starting with AS ABAP 7.00 it was possible to set up an AS ABAP-based SAP system with a stand-alone enqueue services, as part of the central service instance (ASCS). Starting from AS ABAP 7.03 the ASCS was the default installation options for new SAP systems. Starting from AS ABAP 7.50 there are no SAP systems supported any longer without ASCS, which have more than one application server. As of AS ABAP 7.51 the ASCS is mandatory in any case.

AS Java-based SAP systems are always installed with a central service instance (SCS).

Using the classical setup without ASCS there are some single points of failure (SPOF):

• The SAP Message Server can be restarted quite fast. As long as it is not available, there is no communication possible between the application servers, but there is no loss of critical data.

• The PAS (or: central instance) is a SPOF, because it contains the enqueue service. The enqueue service contains the critical lock data in main memory. If the enqueue service fails, the lock data is lost. All transactions holding locks have to be reset.

There are some advantage of a stand-alone enqueue service, as part of the ASCS:

• The communication between the enqueue clients (application servers) and the enqueue server is not established via the corresponding dispatcher any longer, but directly. There is a direct TCP connection between the work process and the enqueue server.

• An ASCS is a prerequisite to make the stand-alone enqueue server high available by using an Enqueue Replication Server (ERS). This can be combined with a suitable cluster software.

When using an ERS, each change of the lock table of the enqueue service is replicated to the ERS. The answer to the requesting enqueue client (the work process) is processed, as soon as the replication is successfully.

The multi threaded architecture of the stand-alone enqueue server allows parallel processing and synchronization with the ERS. The throughput is higher than with a classical set up, using a dispatcher with enqueue work process.

Each work process is connected with the stand-alone enqueue server. The enqueue server is connected with the ERS.

The stand-alone enqueue server communicates vie port sapdp<nn> with its clients. <nn> is the instance number of the ASCS. Because application servers running on the same host communicate using this port, also, the ASCS needs its own instance number.

The enqueue server opens port enq/replicatorport to wait for the connection of the ERS.

• If the stand-alone enqueue server fails, it is restarted by the HA software on the host of the ERS and copies the replication table in main memory from the ERS in order to rebuild its lock table. In other words: the enqueue server follows the ERS.

• If the ERS fails, it can be restarted on a different host. the ERS can copy the entire lock table from the stand-alone enqueue server. During normal run the ERS only receives the delta information from the stand-alone enqueue server.

Before using the ERS, it has to be installed and configured. The following road map shows the essential steps for installation, configuration and usage of the ERS:

Installation

Before installing an ERS, the SAP system must be set up with an ASCS. If the SAP systems is was not installed with an ASCS, you can split off the ASCS, using SWPM (SAPinst). Now the ERS can be installed using SWPM (SAPinst). Use the menu options Additional SAP System Instances in the corresponding section.

File system structure

The ERS is been installed in the /usr/sap/<SID>/ERS<nn> directory. Subdirectory exe contains programs that can check the correctness of replication (ensmon) and can view the lock table (engf).

Profile parameters

The parameters concerning the stand-alone enqueue server are also relevant when not using the ERS.

Profile parameter enqueue/table_size defines the size of the lock table, default is 262144 (= 262 MB).

Start and stop

The ASCS and ERS can be started and stopped using the SAP MC or the SAP MMC. The ERS has to be stated before starting the ASCS. The ASCS has to be stopped before stopping the ERS.

Monitoring

The enqueue server and the ERS can be monitored using ensmon. ensmon connects with the enqueue server. The host name of the enqueue server has to be specified either by providing pf=<profile> or with the options –H <host name> and –I <instance number>. Type ensmon –help for help options.

The ERS is monitored by either the SAP start service or the HA software that monitors the enqueue server and ERS in the HA cluster.

The lock table of the ERS can be monitored using enqt by starting the program on the host of the ERS.

Log file dev_enqsrv is written when starting the enqueue server. Problems with the enqueue processing itself an written to file dev_enqwork. Files dev_enqio_* contain the communication with the enqueue clients. The ERS writes file dev_enrepsrv.