The replicated enqueue server solves the problem of the enqueue service, which is a single point-of-failure. It constitutes a fully transparent solution to this problem and enables the SAP system to continue functioning in the event that an enqueue server fails.
For more information on how this works, see High Availability with the Standalone Enqueue Server.
The enqueue service, consisting of the enqueue server process and the lock table, is a critical component of the SAP system. It administers locks on objects during SAP transactions. The locks are requested by applications in order to ensure the consistency of the SAP system.
Since the lock table is stored in the main memory of the enqueue server, server failure in the absence of high-availability protection leads to total loss of the stored locks, with the following consequences:
· All transactions are automatically rolled back (assuming they are not in the update process), because it is not clear which transactions are holding active locks
· Updates requesting locks are aborted
· However, since transactions must assume that their writes were successful, there is no rollback of database changes occurring in previous steps of the SAP transaction
· Before the SAP system can go back into production operation, the aborted updates must be applied one by one, in order to restore data consistency (otherwise, the data could be used by other transactions, leading to inconsistency)
Since in the standard SAP landscape, only one enqueue service exists for each SAP system, enqueue service failures normally lead to failure of the entire SAP system. That is, the enqueue service is a single point of failure. The replicated enqueue server solves this problem.
Starting with SAP Release 4.6D, the enqueue server and the message server are separate and run independently of the other application servers, as shown in the following graphic:
There are two host machines, one for the standalone enqueue server and one for the replicated enqueue server. Your SAP partner can help you implement this setup using a clustered switchover solution.
The above setup has the following advantages:
· You can restart the two critical components (enqueue server and message server) in the event of failure more quickly than a complete SAP application server.
· You can now replicate the lock table to a standby server, which means that the standby server contains exactly the same information as the primary server.
· The standby server runs a replicated enqueue server that can be activated if the primary enqueue server fails, using the enqueue table copy.
· The result is that, in the event of standalone enqueue server failure, no transactions or updates are lost and the enqueue service for the SAP system continues without interruption.