Managing Serviceguard Extension for SAP, December 2007

Understanding Serviceguard Extension for SAP
The Replicated Enqueue
Chapter 1 31
The Replicated Enqueue
In case an environment has very high demands regarding guaranteed
uptime, it makes sense to activate a Replicated Enqueue with SGeSAP.
With this additional mechanism it is possible to failover ABAP or JAVA
System Central Service Instances without impacting ongoing
transactions on Dialog Instances.
NOTE It only makes sense to activate Enqueue Replication for systems that
have Dialog Instances that run on nodes different from the primary node
of the System Central Service package.
Each SAP Enqueue Service maintains a table of exclusive locks that can
temporarily be granted exclusively to an ongoing transaction. This
mechanism avoids inconsistencies that could be caused by parallel
transactions that access the same data in the database simultaneously.
In case of a failure of the Enqueue Service, the table with all locks that
have been granted gets lost. After package failover and restart of the
Enqueue Service, all Dialog Instances need to get notified that the lock
table content got lost. As a reaction they cancel ongoing transactions that
still hold granted locks. These transactions need to be restarted.
Enqueue Replication provides a concept that prevents the impact of a
failure of the Enqueue Service on the Dialog Instances.
A stand-alone version of the Enqueue Server is included with the
binaries of SAP kernel 6.40. The stand-alone version of the Enqueue
Server has the ability to create a copy of its memory content to a
Replicated Enqueue Service that needs to be running on a remote host.
This is a real-time copy mechanism and ensures that the replicated
memory accurately reflects the status of the Enqueue Server at all times.