Managing Serviceguard Extension for SAP Version B.05.10, September 2010

Figure 1-2 One-Package Failover Scenario
Follow-and-Push Clusters with 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 and/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. Transactions no longer need to be restarted. The Enqueue Server
has the ability to create a copy of its memory content to a Replicated Enqueue Service that needs
to be running as part of a Enqueue Replication Service Instance (ERS) 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.
There might be two ERS instances for a single SAP system, replicating SCS and ASCS locks
separately.
16 Designing SGeSAP Cluster Scenarios