User's Guide

If the primary node fails, the database and the Central Instance fail over and continue functioning on an
adoptive node. After failover, the system runs without any manual intervention needed. All redundant
Application Servers and Dialog Instances, even those that are not part of the cluster, can either stay up or
be restarted triggered by a failover. A sample configuration in Figure 1-2 shows node1 with a failure, which
causes the package containing the database and central instance to fail over to node2. A Quality Assurance
System and additional Dialog Instances get shut down, before the database and Central Instance are
restarted.
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.
Follow-and-Push Clusters with Replicated Enqueue 15