Replikation und Failover 
Bei jeder Änderung an der Sperrtabelle (z.B. wenn der Enqueue-Server einen Enqueue- oder Dequeue-Request bekommt) wird die geänderte Zeile der Sperrtabelle zum Replikationsserver übertragen, der diese dann in die Replikationstabelle übernimmt. Die Antwort des eigentlichen Enqueue-Requests wird erst dann zum Enqueue-Client (Workprozess) geschickt, wenn die Replikation erfolgreich war.
Bevor man die Änderungen an der Sperrtabelle aufzeichnen kann, muss die Replikationstabelle einmal auf den aktuellen Stand gebracht werden. Dies geschieht mittels eines so genannten State Transfer. Der Enqueue-Server schickt dazu die aktuelle Sperrtabelle komplett an den Replikationsserver. Erst dann können die Änderungen an der Sperrtabelle als Delta-Informationen übertragen werden.
Tritt nun ein Fehler bei der Replikation dieser Delta-Informationen auf (z.B. Netzwerkfehler), ist das Replikat veraltet und muss erneut auf den aktuellen Stand gebracht werden (die Delta-Information können nur einmal gesendet werden). Dabei wird nicht der komplette Inhalt der Sperrtabelle zum Replikationsserver gesendet, sondern nur die Zeilen, die dort noch nicht auf dem aktuellen Stand sind (differentieller State Transfer).
Es kann nicht nur bei der Übertragung der Delta-Informationen, sondern auch beim State Transfer (komplett oder differentiell) ein Fehler auftreten. Dann muss erneut ein State Transfer durchgeführt werden.
Auch dieser kann wieder fehlschlagen. Wenn dies dreimal passiert, wird die Replikation angehalten (Replikationszustand suspended). Dieser Zustand wird nach einer konfigurierbaren Zeit (enque/enrep/stop_timeout_s, Standard 300 Sekunden) wieder verlassen und es wird erneut bis zu dreimal versucht, das Replikat auf den aktuellen Stand zu bringen. Scheitert dies wieder, so wird die Replikation wieder in den Zustand suspended gesetzt. Nach weiteren 5 Minuten wird wieder bis zu dreimal versucht, einen State Transfer durchzuführen. Dies wird maximal so oft wiederholt wie durch den Wert von enque/enrep/stop_retries eingestellt. Danach wird der Replikationsserver beendet und muss neu gestartet werden (z.B. durch die HA-Software). Durch dieses Verfahren wird von außen sichtbar, dass ein Problem mit der Replikation vorliegt.
Der Enqueue-Server muss dem Replikationsserver „folgen“, d.h. der Enqueue-Server muss beim Failover auf dem Rechner gestartet werden, auf dem der Replikationsserver läuft, weil dieser die Replikationstabelle in einem Shared Memory Segment hält. Dieses Segment benötigt der neu gestartete Enqueue-Server nach dem Failover, um sich daraus die neue Sperrtabelle zu erzeugen. Anschließend wird dieses Shared Memory Segment gelöscht.
Dieses Konzept kann mit einigen HA-Lösungen nicht ohne weiteres umgesetzt werden, was im Abschnitt Polling-Konzept beschrieben ist.
Folgende Probleme treten im HA-Umfeld mit dem SAP-Replikationskonzept auf:
Die Sperrtabelle wird wie oben beschrieben aus der Replikationstabelle erzeugt, auch wenn der Replikationsserver gar nicht mehr läuft. Da unter Windows Shared Memory Segmente gelöscht werden, sobald kein Prozess mehr mit ihnen verbunden (attached) ist, muss gewährleistet sein, dass der Replikationsserver noch läuft, wenn sich der neu gestartete Enqueue-Server mit dem Shared Memory Segment verbindet. Wenn der Enqueue-Server die Replikationstabelle gelesen hat, teilt er dies dem Replikationsserver über ein Flag im Shared Memory mit. Der Replikationsserver beendet sich dann; die HA-Software muss hier nichts tun.
Manche HA-Softwarelösungen bieten das beschriebene Konzept, dass ein Softwarepaket einem anderen auf dessen Rechner folgt, nicht an. Aus diesem Grund hat SAP das Polling-Konzept eingeführt: Hier muss der Replikationsserver nicht unter der Kontrolle der HA-Software stehen, sondern auf jedem möglichen Failover-Host läuft ein Replikationsserver. Ob Sie dies benötigen, hängt von Ihrer HA-Software ab. Wenden Sie sich dazu an Ihren HA-Software-Partner.
Wenn Sie das Polling benötigen, aktivieren Sie es über den Parameter enque/enrep/poll_interval.