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

Im Hauptspeicher, Shared Memory, des Enqueue-Servers. Zugriff haben alle Workprozesse des Enqueue-Servers. Fremde Applikationsserver lassen ihre Sperroperationen im Enqueue-Prozeß des Enqueue-Servers ausführen. Die Kommunikation erfolgt dann über die betroffenen Dispatcher und den Message-Server.

Ja, die gesicherten Sperren, die an den Verbucher vererbt wurden, werden beim Startup in die Sperrtabelle zurückgeladen (siehe erste Frage).

In Workprozessen des Enqueue-Servers einige 100 Mikrosekunden. In Workprozessen fremder Applikationsserver kommen die Message-Server Kommunikation und 8 Prozeßwechsel hinzu. Abhängig von CPU- und Netzlast zwischen ca. 20 (best case) und ca. 80 (typisch) Millisekunden.

Diagnosefunktionen ausführen:

Lock management operation mode

Was bedeutet diese Meldung, und was sind andere Optionen?

"Internal lock management in same work process" in der Diagnosefunktion bedeutet, daß Sie am Enqueue-Server angemeldet sind und Ihr Workprozeß auf die Sperrtabelle sofort zugreifen kann. Sie muß Enqueue-Anforderungen nicht an einen Enqueue-Prozeß 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.

In jedem SAP-System gibt es genau einen Applikationsserver, der als Enqueue-Server fungiert. Dieser pflegt die Sperrtabelle, die sich in einem Shared-Memory-Segment befindet. Alle Workprozesse auf dem Enqueue-Server können auf die Sperrtabelle zugreifen. Alle Workprozesse auf anderen Applikationsservern delegieren ihre Enqueue-Anforderungen an einen speziellen Enqueue-Workprozeß auf dem Enqueue-Server.

Das Verhalten ist selbstkonfiguriert. Im Default-Profil DEFAULT.PFL gibt die Parameterzeile "rdisp/enqname =<application server name>" Auskunft, welcher Applikationsserver als Enqueue-Server zur Verfügung steht. Stellt ein Applikationsserver fest, daß sein Name mit dem Namen des Enqueue-Servers übereinstimmt, legt er die Sperrtabelle an und alle ihre Workprozesse verarbeiten Enqueue-Anforderungen inline. Stellt ein Applikationsserver fest, daß sein Name nicht mit dem Namen des Enqueue-Servers übereinstimmt, sendet er alle Enqueue-Anforderungen an den Enqueue-Server.

Workprozesse vom Typ Enqueue garantieren die sofortige Verarbeitung eingehender Anforderungen. Normalerweise reicht ein Enqueue-Prozeß aus. In sehr großen SAP-Systemen mit sehr vielen Applikationsservern ist ein zweiter Prozeß vorteilhaft. Es ist jedoch nicht sinnvoll, mehr als zwei Enqueue-Prozesse zu konfigurieren. Wenn mit Transaktion SM50 -> [CPU] zu beobachten ist, daß nur der erste Enqueue-Prozeß benutzt wird, lag das Bottleneck nicht an dieser Stelle.

Bei einem zentralen System wird der Enqueue-Prozeß 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-Prozeß fehlt. Deshalb weist auch die Enqueue-Diagnose einen Fehler aus, wenn kein Enqueue-Prozeß konfiguriert ist.

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

Ja, denn die Workprozesse auf dem Enqueue-Server arbeiten direkt auf die Sperrtabelle, ohne Umweg über den Enqueue-Prozeß. Dieser ist nur für Sperranforderungen aus fremden Applikationsservern zuständig.

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

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.

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.

Es ist zu erwarten, daß 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 daß anzunehmen ist, daß 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, daß 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.

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, daß 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 Workprozeß bleibt zwischen den Sperrversuchen belegt.