Wo liegt die Sperrtabelle?

Im Hauptspeicher, Shared Memory, des Enqueue-Servers. Ist der Enqueue-Server als Enqueue-Workprozess installiert, haben alle Workprozesse dieser Instanz Zugriff auf die Sperrtabelle. Fremde Applikationsserver lassen ihre Sperroperationen im Enqueue-Prozess des Enqueue-Servers ausführen. Die Kommunikation erfolgt dann über die betroffenen Dispatcher und den Message-Server.

Beim Einsatz des Standalone-Enqueue-Servers kommunizieren alle Workprozesse direkt mit dem Enqueue-Server.

Wieso benötigt man bei einem zentralen AS ABAP System überhaupt einen Enqueue-Workprozess? Alle Workprozesse haben doch gleichermaßen Zugang auf das Shared Memory und damit auf die Sperrtabelle.

Bei einem zentralen System wird der Enqueue-Prozess nicht genutzt, er kostet aber auch nichts. Weil aber fast jeder Kunde früher oder später einen Applikationsserver dazunimmt, sind Fehler vorprogrammiert, wenn der Enqueue-Prozess fehlt. Deshalb weist auch die Enqueue-Diagnose einen Fehler aus, wenn kein Enqueue-Prozess konfiguriert ist.

Kann es nach Startup bereits Sperren geben?

Ja, die gesicherten Sperren, die an den Verbucher vererbt wurden, werden beim Startup in die Sperrtabelle zurückgeladen.

Werden die Sperren in der Sperrtabelle auch auf Datenbankebene gesetzt? Wenn Nein, dann ist es möglich, im SAP-System gesperrte Objekte mit Datenbank-Mitteln zu bearbeiten?

Sperren werden nicht in der DB gesetzt, die Sperrtabelle liegt im Hauptspeicher des Enqueue-Servers.

Weitere Informationen: Zusammenhang zwischen SAP-Sperren und Datenbanksperren.

Was bedeutet der _SCOPE-Parameter? Wie ist das mit den Sperreigentümern?

Sperreigentümer

_SCOPE-Parameter

Wie bekomme ich (programmatisch) heraus, wer gerade die nicht gewährte Sperre hält? D.h. wie kann ich nach einem ENQUEUE im Programm ermitteln, welcher Benutzer diese Sperre gerade hält, um es dem Benutzer mitzuteilen?

Nach Return des Funktionsbausteins ENQUEUE_... mit steht der Name des Inhabers der Sperre in SY-MSGV1.

Kann ich in meinem Sperrargument Sonderzeichen, insbesondere das Klammeraffen-Zeichen @, verwenden?

Das @-Symbol dient bei SAP-Sperren (Enqueues) als Wildcard-Zeichen, d.h. es steht bei der Kollisionsprüfung für jedes andere Zeichen an dieser Position. So sperrt zum Beispiel der Parameterwert 12345@ die Mengen 123450 bis 123459, 12345a bis 12345z, 12345A bis 12345Z sowie alle sonstigen Werte mit einem beliebigen Sonderzeichen auf der 6. Zeichenposition.

Weitere Informationen: Kollisionen von Sperren

Um das ungewollte Wirksamwerden des Wildcard-Mechanismus bei SAP-Sperren auszuschließen, muss sichergestellt sein, dass Schlüsselwert-Parameter beim Aufruf von Enqueue-Funktionsbausteinen keine Wildcard-Zeichen enthalten.

Falls Schlüsselwerte, mit denen einzelne Entitäten gesperrt werden sollen, dennoch Wildcard-Zeichen enthalten, müssen diese vor dem Enqueue-Aufruf gegen ein Ersatzzeichen ausgetauscht werden.

Was zuerst tun bei Problemen aller Art?

Diagnosefunktionen ausführen:

Falls irgendwelche Probleme gemeldet werden, die Trace-Dateien dev_w*, dev_disp, dev_eq* sichern, im Syslog nachsehen.

Bei den Diagnoseeinzelheiten in SM12 bekommt man folgende Meldung:

Lock management operation mode

Internal lock management in same process

Was bedeutet diese Meldung, und was sind andere Optionen?

Internal lock management in same work process in der Diagnosefunktion bedeutet, dass Sie am Enqueue-Server angemeldet sind und Ihr Workprozess auf die Sperrtabelle sofort zugreifen kann. Sie muss Enqueue-Anforderungen nicht an einen Enqueue-Prozess auf dem entfernten Enqueue-Server delegieren. Sind Sie an einem Applikationsserver angemeldet, der kein Enqueue-Server ist, teilt Ihnen die Diagnosefunktion den Namen des Enqueue-Servers mit.

Im Syslog finden sich öfters Meldungen wie z.B. die folgende: Enqueue: Bisher aufgelaufene Wartezeit beim Sperren: 2500 Sekunden. Wie sollte vorgegangen werden, um das Problem zu analysieren? Oder ist dieser Eintrag nicht kritisch? (Abbrüche oder Timeouts wurden nicht bemerkt.)

Die Meldung ist als Information zu verstehen, gibt aber u.U. Hinweise auf gestörten Parallelbetrieb von ABAP-Programmen. Es wird die Wartezeit angegeben, die seit Startup durch die Verwendung der WAIT-Parameters beim Aufruf von Enqueue-Funktionsbausteinen aufgelaufen ist.

Der WAIT-Parameter ermöglicht, dass ein Sperrversuch einige Male wiederholt werden kann, z.B. um im Verbucher nicht abbrechen zu müssen, wenn eine Sperre kurzzeitig von anderen Programmen gesetzt ist. Der Workprozess bleibt zwischen den Sperrversuchen belegt.

Was passiert mit Sperren, wenn der Enqueue-Server durchgestartet wird?

Beim klassischen Enqueue oder STandalone-Enqueue ohne Replikation gehen die Sperren verloren, sofern sie nicht ins Backup-File auf Platte gesichert wurden. Auf Platte werden diejenigen Sperren gesichert, die bei COMMIT WORK nach CALL FUNCTION .. IN UPDATE TASK an den Verbucher vererbt werden. Die Sicherung auf Platte erfolgt zu dem Zeitpunkt, zu dem der Verbuchungsauftrag gültig wird, also im o.g. COMMIT WORK. Bei jedem Neustart des Enqueue-Servers werden die auf Platte gesicherten Sperreinträge in die Sperrtabelle zurückgeladen.

Eine Sperre wird genau dann auf Platte gespeichert, wenn das Backupflag gesetzt ist.

Wenn der Enqueue Replication Service als Teil einer Hochverfügbarkeits-Lösung verwendet wird, gehen Sperren auch beim Ausfall oder Durchstart des Enqueue-Servers nicht verloren.

Der Enqueue-Server ist ein Single-Point-Of-Failure im SAP-System. Kann ich Hochverfügbarkeit für den Enqueue-Server gewährleisten?

Hierzu müssen Sie den Standalone-Enqueue-Server mit Replikationsserver einsetzen. Dies ist in der Dokumentation Standalone-Enqueue-Server beschrieben.

In SAP-Hinweis 524816 finden Sie die Voraussetzungen, die zum Einsatz des Standalone-Enqueue-Servers mit Replikationsserver erfüllt sein müssen.

Wie schnell sind Sperroperationen?

In Workprozessen des Enqueue-Servers einige 100 Mikrosekunden. In Workprozessen fremder Applikationsserver kommen Netzwerk-Kommunikation und Prozesswechsel hinzu. Abhängig von CPU- und Netzlast wenige Millisekunden.

Mit einem Single-Prozessor-System als Enqueue-Server haben wir X SD Benchmark Benutzer erreicht. Kann durch Einsatz eines Multiprozessor-Systems diese Zahl gesteigert werden (Message Server auf der gleichen Maschine wie Enqueue)? Ist die Skalierung linear zu erwarten (Anzahl CPUs * X SD user)? Wieviele Prozessoren sind sinnvoll, wenn Message-Server, Dispatcher, ein Dialog und zwei Enqueue Prozesse auf dem System laufen sollen?

Es ist zu erwarten, dass durch Einsatz von mehr Prozessoren der Durchsatz des Enqueue-Servers deutlich gesteigert werden kann. Die CPU-Last am Enqueue-Server verteilt sich ziemlich gleichmäßig auf Message-Server, Dispatcher und Enqueue-Workprozesse, so dass anzunehmen ist, dass bis zu 3 Prozessoren gleichzeitig beschäftigt werden können. Dispatcher und Message-Server bilden den Bottleneck beim Enqueue.

Eine lineare Skalierung ist bis 3 Prozessoren zu erwarten, und auch nur dann, wenn Sperranforderungen so häufig eintreffen, dass Message-Server, Dispatcher und Workprozesse gleichzeitig beschäftigt sind. Wegen asynchroner Systemprozesse (z.B. Syncer) kann der Einsatz von mehr Prozessoren den Durchsatz dennoch weiter verbessern.