Standalone Enqueue Server 
Implementation
If you want to guarantee high availability for your SAP system from all the software and hardware components you are using, you will benefit from using the standalone enqueue. The use of the standalone enqueue server means that the crucial component (enqueue server with lock table) is kept as small as possible. Instead of the classical central instance in your system (entire application server with enqueue work process and lock table – usually the message server also runs on this server), you have one slim line central instance consisting of the enqueue server and the message server only. It is far easier to make this one central instance a high availability (HA) solution.
The standalone enqueue server provides the following benefits:
● The enqueue clients (SAP application servers) and the enqueue server communicate directly, that is, the work process has a TCP connection to the enqueue server. They no longer communicate via the dispatchers and the message server (see Functions of the SAP Lock Concept).
● You can implement the standalone enqueue server as part of the high availability enqueue server solution (with replication server) and thus make the enqueue server breakdown-proof. See also: High Availability with the Standalone Enqueue Server.
Integration
An SAP system contains several single points of failure (SPOF). If these fail, not all of them can simply be restarted on another computer:
● The SAP message server can be restarted quickly and easily. While this server is down, the application servers cannot communicate with each other, but no important data is lost.
● The SAP database has to be secured by means of database failover solutions.
● The SAP central instance (the classical model) is a single point of failure because of the enqueue services that it provides.
The enqueue server keeps critical data (that is, all locks currently in use by users in the system) in the lock table in the main memory. If the host fails this data is lost and cannot be restored even when the enqueue server is restarted. All transactions that have held locks must therefore be reset.
We therefore recommend that you use the standalone enqueue server, so that you do not have to implement high availability for the entire central instance. The standalone enqueue server, together with the enqueue replication server that runs on another machine is a high availability solution. Your SAP system no longer has a central instance in the classical sense (as shown in the graphic above).
Features
You can use the standalone enqueue server either alone or with an enqueue replication server as part of a high availability enqueue server scenario. The high availability scenario is described in section High Availability with the Standalone Enqueue Server.
Thanks to the multithreaded architecture of the standalone enqueue server, enqueue request processing and synchronization of the lock table with the replication server can be carried out in parallel.
The I/O load, which on a conventional SAP system is dealt with sequentially by the dispatcher, is distributed across several threads. In most cases, this makes it possible to process a higher number of enqueue requests.
For details of the functions see:
High Availability with the Standalone Enqueue Server
The following sections describe how to implement and monitor the standalone enqueue server:
Installing the Standalone Enqueue Server
Monitoring the Standalone Enqueue Server
Profile Parameter Settings for the Standalone Enqueue Server
Restrictions
If your SAP system has only one instance (central system), you do not need to use the standalone enqueue server. The work processes of the central instance can directly access the enqueue functionality (see Functions of the SAP Lock Concept).