SAP-Sperrkonzept 
Mit dieser Funktion programmieren und verwenden Sie unterschiedliche Arten von Sperren in Ihren SAP-Programmen. Dazu nutzen Sie die Sperrverwaltung.
In einer SAP-Transaktion arbeiten Sie mit SAP-Sperren. Das System setzt im Verlauf der Transaktion auch eine Datenbanksperre, wobei die Datenbanksperre viel kürzer besteht als die SAP-Sperre. Die SAP-Sperre kann über mehrere Datenbank-LUWs hinweg bestehen, eine Datenbanksperre hingegen nicht.
Weitere Informationen: Zusammenhang zwischen SAP-Sperren und Datenbanksperren.
Arten von Sperren
Sie können verschiedene Arten von Sperren verwenden.
Der Sperrmodus beschreibt, um welche Art Sperre es sich handelt. Folgende Sperrmodi sind möglich.
Art der Sperre |
Sperrmodus |
Bedeutung |
|---|---|---|
Lesesperre |
S (Shared) |
Mehrere Benutzer (Transaktionen) können gleichzeitig im Anzeigemodus auf die gesperrten Daten zugreifen. Die Anforderungen weiterer Lesesperren werden akzeptiert, auch wenn diese von anderen Benutzern kommen. Eine Schreibsperre (E) von einem anderem Benutzer auf ein Objekt, das schon eine Lesesperre hat, wird zurückgewiesen. Außerdem wird jede erweiterte Schreibsperre (X) zurückgewiesen. |
Schreibsperre |
E (Exclusive) |
Eine Schreibsperre schützt das gesperrte Objekt gegen Sperren aller Art anderer Transaktionen. Nur derselbe Sperreigentümer kann die Sperre erneut setzen (kumulieren). |
Erweiterte Schreibsperre |
X (eXclusive non-cumulative) |
Während Schreibsperren mehrfach von der gleichen Transaktion angefordert und sukzessive wieder abgebaut werden können, kann eine Erweiterte Schreibsperre auch von der gleichen Transaktion nur ein einziges Mal angefordert werden. Jede weitere Anforderung einer Sperre wird abgewiesen. |
Optimistische Sperre |
O (Optimistic) |
Optimistische Sperren verhalten sich zunächst wie Lesesperren und können in Schreibsperren umgewandelt werden. Weitere Informationen: Optimistische Sperren. |
Hinweis
Es gibt noch weitere Sperrmodi, die im Gegensatz zu den hier beschriebenen keine Sperre setzen, sondern nur die Kollisionsprüfung durchführen. Aus diesem Grund tauchen diese Sperrmodi auch nicht in der Sperrtabelle auf.
Weitere Informationen: Beispiel: Verwendung der Prüfungs-Sperrmodi
Sperrserver und Enqueue-Kommunikation
In einem verteilten SAP-System gibt es einen einzigen Sperrserver (auch „Enqueue-Server“ genannt), der die Sperrtabelle verwaltet.
Weitere Informationen: Enqueue-Server.
Sperren und SAP-Verbuchung (SAP NetWeaver AS ABAP)
Die Sperre wird im Laufe der Transaktion an die SAP-Verbuchung übergeben. Sperren, die an die Verbuchung übergeben wurden, werden auch zusätzlich zur Sperrtabelle in einer Backup-Datei gespeichert, sodass sie nicht verloren gehen, wenn der Enqueue-Server ausfällt. In der Sperrverwaltung ist dann das Backup-Flag gesetzt.
Weitere Informationen:
Sperreigentümer und Funktionsbausteine für Sperranforderungen.
SAP-Sperren und Datenbanksperren (SAP NetWeaver AS ABAP)
Der Zusammenhang zwischen SAP-Sperren und Datenbanksperren ist im Abschnitt Zusammenhang zwischen SAP-Sperren und Datenbanksperren beschrieben.
Ziel ist, die Zeitspanne einer Datenbanksperre zu minimieren. Des Weiteren kann eine SAP-Sperre über mehrere Datenbank-LUWs hinweg bestehen, eine Datenbanksperre hingegen nicht. Der Unterschied zwischen SAP-LUW und Datenbank-LUW ist unter Funktionsweise der Verbuchung beschrieben.
Lebensdauer von SAP-Sperren
Eine Sperre besteht immer so lange, bis Sie entweder den entsprechenden DEQUEUE-Funktionsbaustein aufrufen oder die Transaktion mit einem impliziten DEQUEUE_ALL endet.
Gesicherte Sperren, die an den Verbucher vererbt wurden, werden beim Startup in die Sperrtabelle zurückgeladen.
Dauer von Sperroperationen
Die Dauer von Sperroperationen beträgt in Workprozessen des Enqueue-Servers einige 100 Mikrosekunden. In Workprozessen fremder Applikationsserver oder beim Einsatz des Standalone-Enqueue-Servers kommen Netzwerk-Kommunikation und Prozesswechsel hinzu. Abhängig von CPU- und Netzlast beträgt die Dauer hier wenige Millisekunden.
Gültige Zeichen
Sie können in Ihrem Sperrargument nur druckbare Zeichen verwenden. Datentypen, die diese Anforderung nicht erfüllen, müssen vor ihrer Verwendung im Sperrargument in einen entsprechenden String konvertiert werden.
Wildcards
Sie können in Ihrem Sperrargument Sonderzeichen, insbesondere das kommerzielle a (@), verwenden. Es dient bei SAP-Sperren (Enqueues) als Wildcard-Zeichen, d. h., es steht bei der Kollisionsprüfung für jedes andere Zeichen an dieser Position.
Hinweis
Um das ungewollte Wirksamwerden des Wildcard-Mechanismus bei SAP-Sperren auszuschließen, müssen Sie sicherstellen, dass Schlüsselwert-Parameter beim Aufruf von Enqueue-Funktionsbausteinen keine Wildcard-Zeichen enthalten. Wenn Schlüsselwerte, mit denen einzelne Entitäten gesperrt werden sollen, dennoch Wildcard-Zeichen enthalten, müssen Sie diese vor dem Enqueue-Aufruf gegen ein Ersatzzeichen austauschen.
Sperren in ABAP-Programmen
Wenn Sie eine SAP-Transaktion programmieren, die Datenbankobjekte verändern soll, müssen Sie diese Objekte vorher gegen konkurrierenden Zugriff sperren und anschließend wieder freigeben. Dazu definieren Sie im Data Dictionary ein Sperrobjekt und aktivieren es anschließend. Das Aktivieren bewirkt, dass das System zwei Funktionsbausteine generiert: einen für das Sperren des Objekts, einen für das Freigeben.
Weitere Informationen finden Sie in der Data-Dictionary-Dokumentation in den folgenden Abschnitten:
Weitere Informationen
Details zur Funktionsweise des Sperrkonzepts finden Sie in den folgenden Abschnitten.