Verkehrsregeln für Datensätze

Was ist eine Transaktion?

| Autor / Redakteur: Otto Geißler / Ulrike Ostler

Transaktionen sollen entweder vollständig oder gar nicht ausgeführt werden.
Transaktionen sollen entweder vollständig oder gar nicht ausgeführt werden. (Bild: © djama - stock.adob.com)

Eine Transaktion beschreibt in der Informatik eine Folge von Operationen (Instruktionen) oder Programmschritten, die eine logische Einheit bildet und einen Datenbestand nach fehlerfreier Ausführung in einem konsistenten Zustand hinterlässt.

Transaktionen kommen meist in Zusammenhang mit Datenbanksystemen zum Einsatz. Beispiel sind Überweisungssysteme einer Bank und generell Buchungssysteme, Tauchen während einer Transaktion Fehler auf, so müssen diese fehlerhaften Transaktionen abgebrochen und alle dazu ausgeführten Änderungen in der Datenbank als Rollback rückgängig gemacht werden. Damit werden negative Auswirkungen auf den Bestand der Datenbank ausgeschlossen.

Datenbanksystem und ACID-Prinzip

Bei der Ausführung von Transaktionen muss das Datenbanksystem sich immer an den folgenden vier grundsätzlichen ACID-Eigenschaften orientieren: Atomicity, Consistency, Isolation und Durability.

Atomarität (Atomicity)

Transaktionen werden entweder ganz ausgeführt oder gar nicht. Somit sind sie grundsätzlich unteilbar. Beim Abbruch einer „atomaren“ Transaktion wird im Falle eines Fehlers die jeweilige Aktion rückgängig gemacht (Rollback).

Konsistenz (Consistency)

Nach Abschluss der Transaktion muss sich die Datenbank wieder wie zuvor in einem konsistenten Zustand befinden. Diese Konsistenz wird durch festgelegte Integritätsbedingungen abgesichert. Werden sie verletzt, so wird die Transaktion zwangsläufig zurückgesetzt. Den Vorgang des Rücksetzens am Ende einer Transaktion nennt man auch „verzögerte Integritätsbedingungen“.

Isolation (Isolation)

Müssen gleichzeitig mehrere Transaktionen ausgeführt werden, so dürfen sich diese – im Sinne der geforderten Konsistenz -nicht gegenseitig beeinflussen und laufen isoliert ab. Aus diesem Grunde steuert ein Datenbankmanagementsystem alle erforderlichen Mechanismen zur Synchronisierung der Transaktionen.

Dauerhaftigkeit (Durability)

Als vierte Eigenschaft müssen Transaktionen persistent sein. Das bedeutet, eine Transaktion gilt erst dann als erfolgreich ausgeführt, wenn sie die Fähigkeit besitzt, dauerhaft im Datenbestand beständig sein kann. Die Auswirkungen von Transaktionen dürfen also nicht verloren gehen oder mit der Zeit an Wirkung nachlassen. Dies wird wiederum durch eine entsprechende Verwaltung gewährleistet.

Transaktionssystem und ACID-Eigenschaften

Das Transaktionssystem zielt darauf ab, möglichst viele Transaktionen in möglichst kürzester Zeit zu bedienen. Eine serielle Realisierung der Transaktionen ist zwar einfach, liefert aber keine besonders ausgeprägte Performanz. Aus diesem Grund splittet das Transaktionssystem die Transaktionen in ihre einzelnen Operationen auf und fügt sie wiederum in Anbetracht der ACID-Eigenschaften zu sogenannten Historien zusammen.

Commit und Abort

Daraus resultieren zwei Möglichkeiten, um eine Transaktion zu finalisieren: Commit (end of transaction) oder Abort. Im ersteren Fall wurde die Transaktion problemlos beendet und das Ergebnis dauerhaft abgespeichert. Bei einem Abort sind Probleme aufgetreten und die Ausführung wurde nicht fortgesetzt und ein Rollback setzte sämtliche Auswirkungen der Transaktion auf den Datenbestand der Ausgangssituation zurück.

Kaskadierende Rücksetzungen

Jedoch kann es sein, dass der Rollback mehre Rücksetzungen erfordert, wodurch sogenannte Ketten von Zurücksetzungen entstehen. Dies nennt man dann kaskadierende Rücksetzen. Wenn eine Transaktion aufgrund einer anderen Aktion nicht realisiert werden kann, spricht man von einer Blockierung. Wird die erste Transaktion durch die zweite Aktion und gleichzeitig die zweite durch die erste blockiert, so nennt man das Deadlock (Verklemmung).

Transaction Isolation-Levels

Parallele Transaktionsprozesse werden in einzelne Grade unterschieden und durch den Isolation Level bestimmt. Je höher der Level, umso geringer ist das Risiko, dass Probleme hinsichtlich der Konsistenz der Daten auftauchen könnten, aber auch umso geringer ist der Durchsatz der Anzahl gleichzeitiger Zugriffe. Dies ist der Tatsache geschuldet, dass Datensätze zeitweilig gesperrt werden.

Der SQL2-Standard definiert zum Beispiel vier Transaction Isolation-Levels:

Ebene 0 - (read uncommitted)

Datensätze werden nicht gesperrt. Der Zugriff über andere Transaktionen ist parallel möglich. Dabei können neue und veraltete Daten – gemäß dem Prinzip dirty read - gelesen werden.

Ebene 1 – (read committed)

Während des Schreibens werden die von einer Transaktion modifizierten Datensätze gesperrt. Beim Lesen sind sie jedoch weiter verfügbar. Hier kann das Problem des „inkonsistenten Lesens“ auftreten.

Ebene 2 – (repeatable read)

Alle Datensätze, die sich während einer Transaktion im Schreib- oder Lesemodus befinden, werden gesperrt.

Ebene 3 – (serialize)

Bei einer vollständigen Serialisierbarkeit der Datensätze erhalten die in einer Transaktion gelesenen Daten bis zum Ende einer Transaktion ihre Gültigkeit.

Verteilte Transaktionen

Werden Transaktionen in verteilten Systemen als verschiedene Teiltransaktionen ausgeführt, so nennt man dies verteilte Transaktionen. Damit die Atomarität auch für verteilte Transkationen gültig ist, müssen Commit-Protokolle zum Einsatz kommen.

Dies wird durch das Beispiel einer Überweisung von dem Datenbanksystem der Überweiserbank an das Datenbanksystem der Empfängersbank deutlich. Sollte nach dem Geldtransfer seitens der Empfängerbank eine ungültige Kontonummer erkannt werden, so muss das Geld automatisch wieder zurücküberwiesen werden.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 45666437 / Definitionen)