Ansicht
Dokumentation

ABENDB_LOCK - DB LOCK

BAL_S_LOG - Application Log: Log header data   Fill RESBD Structure from EBP Component Structure  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Datenbanksperren

Die Synchronisation des gleichzeitigen Zugriffs mehrerer Transaktionen wird in jedem Datenbanksystem durch Datenbanksperren realisiert. Durch diesen Mechanismus

• können Datenobjekte, die eine Transaktion gerade ändert oder liest gegen paralleles Verändern durch andere Transaktionen geschützt werden und

• kann sich eine Transaktion dagegen schützen, Datenobjekte zu lesen, die noch nicht durch eine andere Transaktion festgeschrieben sind.

Die folgenden Abschnitte gehen kurz auf die Eigenschaften von Datenbanksperren ein:

Setzen von Sperren

Datenbanksysteme kennen keine expliziten Befehle zum Setzen von Sperren. Das Setzen von Datenbanksperren erfolgt implizit bei jedem Zugriff auf Daten der Datenbank. In ABAP erfolgen Datenbankzugriffe durch

• Verwendung einer der -Anweisungen SELECT, INSERT, UPDATE, MODIFY, DELETE.

• Verwendung einer Native-SQL-Anweisung.

• Aufruf von AMDP-Methoden.

• Verwendung anderer Anweisungen, die auf die Datenbank zugreifen, wie IMPORT und EXPORT FROM und TO DATABASE.

Gesperrte Objekte

Datenbanksysteme setzen physische Sperren: Gesperrt werden alle von einem Datenbankaufruf betroffenen Zeilen - bei SELECT sind dies die selektierten, bei UPDATE, DELETE, INSERT und MODIFY sind dies die zu verändernden, zu löschenden, bzw. die hinzuzufügenden Zeilen.

Man nehme zum Beispiel folgenden Aufruf:

SELECT SINGLE FOR UPDATE * FROM sflight
  WHERE
    carrid   = 'LH'       AND
    connid   = '0400'     AND
    fldate   = '19960516'
  INTO ... .

Er sperrt die zum Lufthansaflug 0400 am 16.05.1996 gehörende Zeile der Tabelle SFLIGHT.

Dies bedeutet nicht, dass die Tabellenzeile auch immer wirklich die Einheit ist, die gesperrt wird. Andere Einheiten, die gesperrt werden können, sind z.B. Tabellen, Datenseiten oder Indexseiten. Welche Einheiten tatsächlich bei einem Aufruf gesperrt werden, hängt immer vom eingesetzten Datenbanksystem und vom jeweiligen Zugriff ab.

Sperrmodus

Prinzipiell reicht ein Typ von Sperre aus, um konkurrierende Zugriffe auf Daten zu steuern. Um aber eine höhere Parallelität von Transaktionen zu erreichen, kennen Datenbanksysteme mehrere Arten von Sperren. Diese können von Datenbanksystem zu Datenbanksystem variieren. Zum Verständnis des Sperrmechanismus genügen aber zwei:

• Lesesperre (shared lock)

Erlaubt das gleichzeitige Setzen weiterer Lesesperren, verbietet aber anderen Transaktionen das gleichzeitige Setzen von Schreibsperren für die so gesperrten Objekte.

• Schreibsperre (exclusive lock)

Erlaubt anderen Transaktionen keine gleichzeitigen Sperren für die so gesperrten Objekte.

Die Anweisungen SELECT SINGLE FOR UPDATE, INSERT, UPDATE, MODIFY und DELETE, die entsprechenden Native-SQL-Anweisungen oder plattformabhängigen Anweisungen in AMDP-Methoden sowie EXPORT TO DATABASE setzen Schreibsperren.

Ob die SQL-Anweisung SELECT eine Lesesperre setzt oder nicht, hängt von der aktuellen Isolationsebene ab:

• Bei allen Datenbanken außer der SAP-HANA-Datenbank und Oracle-Datenbanken sind folgende Einstellungen möglich:

• Beim Uncommitted Read (Standardeinstellung) wird nicht versucht, eine Lesesperre zu setzen. Es werden auch Daten gelesen, die noch durch eine Schreibsperre geschützt, also noch nicht mit einem Datenbank-Commit festgeschrieben sind.

• Beim Committed Read (einstellbar über Funktionsbaustein DB_SET_ISOLATION_LEVEL) wird während des Lesevorgangs eine Lesesperre gesetzt und danach wieder aufgehoben. Dies ist nur möglich, wenn keine Schreibsperre besteht, so dass es zu Wartezeiten kommen kann.

• Die SAP-HANA-Datenbank und Oracle-Datenbanken setzen keine Lesesperren, lesen aber nur Daten, die durch einen Datenbank-Commit festgeschrieben sind.

Kann eine Transaktion ein Objekt nicht sperren, weil bereits eine andere Transaktion dies macht, so wartet sie, bis die andere Transaktion diese Sperre aufgibt. Es kann deshalb prinzipiell zu einem Deadlock kommen. Ein Deadlock entsteht z.B., wenn zwei Transaktionen auf jeweils eine Sperre warten, die von der anderen gehalten wird.

Beispiel

In einem Flugreservierungssystem soll eine Buchung für den Lufthansaflug 0400 am 16.05.1996 vorgenommen werden. Dies darf nur dann geschehen, wenn die Anzahl der freien Plätze noch ausreicht. Um zu verhindern, dass zwei Flugbuchungen parallel vorgenommen werden und es so zu einer Überbuchung kommt, muss die diesem Flug entsprechende Zeile der DDIC-Datenbanktabelle SFLIGHT gegen Zugriffe durch andere Transaktionen mit einer Sperre geschützt werden. Dadurch wird sichergestellt, dass das Abfragen nach der Zahl der freien Plätze im Feld SEATSOCC, das Hinzufügen der Flugbuchung und die Änderung des Feldes SEATSOCC ungestört von anderen Transaktionen erfolgen können. Der folgende Programmausschnitt zeigt eine Lösung für dieses Problem:

DATA: sflight_wa TYPE sflight, sbook_wa type sbook.
SELECT SINGLE FOR UPDATE *
  FROM sflight
  WHERE
    carrid   = 'LH'       AND
    connid   = '0400'     AND
    fldate   = '19960516'
  INTO @sflight_wa.
IF sy-subrc <> 0.
  MESSAGE e...
ENDIF.
IF sflight_wa-seatsocc  sflight_wa-seatsmax.
  sbook_wa-carrid = 'LH'.
  sbook_wa-connid = '0400'.
  sbook_wa-fldate = '19960516'.
  ...
  INSERT sbook FROM sbook_wa.
  IF sy-subrc <> 0.
    MESSAGE e...
  ENDIF.
  UPDATE sflight
    SET
      seatsocc = seatsocc + 1
    WHERE
      carrid   = 'LH'       AND
      connid   = '0400'     AND
      fldate   = '19960516'.
ELSE.
  MESSAGE e...
ENDIF.
COMMIT WORK.

Die durch SELECT SINGLE FOR UPDATE selektierte und die durch INSERT eingefügte Tabellenzeile sind bis zum Ende der Datenbank-LUW gesperrt. Es kann deshalb weder zu einer Überbuchung des Fluges noch zu einer Inkonsistenz zwischen den Tabellen SFLIGHT und SBOOK bei einem eventuellen Datenbank-Rollback im Fehlerfall kommen.

Sperrdauer

Datenbanksysteme kennen keine expliziten Anweisungen zum Freigeben von Sperren. Alle Sperren werden beim Datenbank-Sperrmechanismus spätestens beim nächsten Datenbank-Commit bzw. -Rollback freigegeben. Lesesperren haben meist eine noch kürzere Lebensdauer. Für Transaktionen, die mehrere Dialogschritte umfassen, entsteht daraus u.U. ein Problem:

Im obigen Beispiel werden nach der Auswahl eines Fluges mit freien Plätzen normalerweise weitere Dialogschritte folgen, um zusätzliche Daten für die Reservierung zu erfassen. Damit erfolgt das Hinzufügen der Flugreservierung in einer anderen Datenbank-LUW als die ursprüngliche Auswahl des Fluges. Mit dem Datenbank-Sperrmechanismus können Sie deshalb nicht verhindern, dass in der Zwischenzeit eine andere Transaktion diesen Flug ausbucht und die geplante Buchung letztendlich zurückgewiesen werden muss.

Aus Sicht des Benutzers besitzt diese Lösung einen erheblichen Mangel an Komfort. Soll dies vermieden werden, muss ein Flugreservierungssystem den SAP-Sperrmechanismus benutzen, um den Flug für die gesamte Dauer der Transaktion zu sperren.

Monitoring-Sperren

Im DBA Cockpit sind Monitoring-Datenbanksperren möglich.

Addresses (Business Address Services)   CPI1466 during Backup  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 11483 Date: 20240523 Time: 164557     sap01-206 ( 197 ms )