Enqueue Replication

[Former Member]

Dear All,

We have the following setup.

Two HP BL860 Server which are in cluster (HP SeviceGuard)

EVA

-O/S : HP-UX 11.31

We are installing SAP ECC 6.0 using Hig Availibity option. (i.e. DB/CI on one node and Dialog instance on another node)

I wanted to know about Enqueue Replication and how it will be benifited to us?

Thanks in advance

[Former Member]

Hi Nirav,

Below a text about the central services (ASCS/SCS) instance and the Enqueue Replication service. I hope this clarifies the basic concepts and why enqueue replication can be useful.

Regards,

Mark

Enqueue and message service as single point of failure

The enqueue service is a critical component of the SAP system. It administers locking using objects within SAP transactions that can be requested by applications to ensure consistency within the SAP system.

In the original architecture of the ABAP server, the enqueue service was implemented as a work process inside the Central Instance. "Enqueue" was simply one of the specialized tasks that could be assigned to a work process, along with dialog, background, update (V1 and V2) and spool. In a SAP system with multiple instances, the enqueue work process only ran in one of these instances. The instance running the enqueue work process, together with the message server, was defined as the "Central Instance".

While this configuration is still the rule, it is not the ideal choice in an environment set up for High Availability (HA). The reason for this is that both the enqueue server and message server constitute a Single Point of Failure (SPOF). By integrating the enqueue and message services into an SAP instance, that entire instance thereby becomes a SPOF. In an HA setup, the consequence is that the entire CI must be able to fail over to another server.

Central Services instance

By isolating the enqueue and message services in a separate instance, only this small instance must be protected in HA. The application instances themselves are no longer critical because they no longer contain any SPOFs and therefore are totally interchangeable.

For the WebAS Java, a separate instance with only the enqueue and message servers has existed since NetWeaver 2004. For Java, such instance is necessary regardless of whether the system is in HA or not, because the functionality is part of the normal SAP kernel and not of the Java processes. The enqueue and message server instance for the WebAS Java is known as the SCS (SAP Central Services) instance.

On the WebAS ABAP side, the same concept can (and with HA should) be used on the ABAP side. This is known as an ASCS (ABAP central Services) instance.

Enqueue replication

The most critical part of a central service instance is the enqueue service. This is because the lock table is held in a non-persistent manner, namely in a shared memory segment in the main memory of the server. A failure of the enqueue server without additional backup measures results in the loss of all the locks held.

After the central services instance has been switched over to another host, the enqueue service is restarted. However, external SAP NetWeaver application servers on different hosts might still be holding open, uncommitted transactions. These can hold enqueue locks that have been lost but are not visible anywhere in the entire SAP system. If no precautions are taken, any user in the SAP system can then lock the same object and change it in the database, which can cause an inconsistent database. To protect the system against this and impose consistency, all open transactions in the entire SAP system are aborted and rolled back before the enqueue server is restarted.

This means that for the enqueue service standard failover scenarios do not offer sufficient protection. An open transaction is unable to survive even a momentary loss of the enqueue service; it will inevitably be rolled back, however short the time window during which the enqueue service was down.

The enqueue replication server (ERS) is used to bridge the interval between the time when the Central Services instance fails and the time when it is restarted under control of the HA software. The ERS runs on the failover host and contains a replica of the lock table. When the Central Services instance fails, it is restarted by the cluster software on the replication server. The replica of the lock table stored on the replication server is transferred to the (A)SCS instance and is used to build the real lock table. The cluster software also ensures that access attempts from clients go through the replication enqueue server while the (A)SCS instance is out of action.