Heim

Isolation (Datenbank)

In der Informatik bezeichnet der Begriff Isolation die Trennung von Transaktionen auf eine Weise, dass eine laufende Transaktion nicht von einer parallel ablaufenden Transaktion durch Änderung der benutzten Daten in einen undefinierten Zustand gebracht werden kann. Die Isolation ist eine der vier ACID-Eigenschaften.

Inhaltsverzeichnis

Beispiel

Das folgende ist ein Beispiel für eine Transaktion in Bezug auf die Datenbank eines Warenlagers. Genauer handelt es sich um eine mögliche Transaktion, die beim Einfügen eines neuen Artikels in ein Warenwirtschaftssystem auftreten könnte.

Transaktionsanfang
Selektiere alle Datensätze, die in der Spalte Titel den Text "Kekspudding" enthalten (Aktion 1)
Wenn ein solcher Datensatz existiert
warne den Benutzer und zeige den existierenden Eintrag an
sonst
Füge Eintrag "Kekspudding" hinzu (Aktion 2)
Transaktionsende

Während dieser Datenbanktransaktion treten mindestens ein oder höchstens zwei einzelne Arbeitsschritte auf. Geben nun zwei Benutzer zum gleichen Zeitpunkt denselben Datensatz in das hypothetische Warenwirtschaftssystem ein, kann es passieren, dass die entsprechenden Transaktionen auf ungünstige Weise parallel ablaufen:

Zeitpunkt Transaktion 1 Transaktion 2 Ergebnis
1 Aktion 1 Keine Einträge gefunden.
2 Aktion 1 Keine Einträge gefunden.
3 Aktion 2 Eintrag wird hinzugefügt.
4 Aktion 2 Eintrag wird nochmal hinzugefügt.

Durch Isolation dieser beiden, parallel ablaufenden Transaktionen kann die Doublettenbildung vermieden werden. Bei Isolation durch Serialisierung (strikte Trennung von Transaktionen und deren Ausführung in Folge) könnte dieser Ablauf beispielsweise wie folgt aussehen:

Zeitpunkt Transaktion 1 Transaktion 2 Ergebnis
1 Aktion 1 Keine Einträge gefunden.
2 Aktion 1 Tabelle gesperrt: Transaktion muss warten.
3 Aktion 2 Eintrag wird hinzugefügt.
4 Aktion 1 Transaktion wird fortgeführt. Neuer Datensatz wird gefunden.

Mögliche Probleme

Bei Datenbanken können durch mangelnde Transaktionsisolation im Wesentlichen die folgenden Probleme auftreten:

  1. Lost Updates: Zwei Transaktionen modifizieren parallel denselben Datensatz und nach Ablauf dieser beiden Transaktionen wird nur die Änderung von einer von ihnen übernommen.
  2. Dirty Read: Daten einer noch nicht abgeschlossenen, anderen Transaktion werden gelesen.
  3. Non-Repeatable Read: Wiederholte Lesevorgänge liefern unterschiedliche Ergebnisse.
  4. Phantom Read: Suchkriterien treffen während einer Transaktion auf unterschiedliche Datensätze zu, weil eine (während des Ablaufs dieser Transaktion laufende) andere Transaktion Datensätze hinzugefügt, entfernt oder verändert hat.

Transaktionsisolation bei SQL

Der ANSI/ISO SQL-Standard (SQL92) des Datenbankinterface SQL sieht vier Transaktionsisolationsebenen vor, die allerdings nicht alle von sämtlichen Datenbanksystemen unterstützt werden. Die folgende Tabelle gibt eine Übersicht über die Güte und die auftretenden Probleme bei Einsatz der verschiedenen Isolationsebenen:

Isolationsebene Dirty Read Non-Repeatable Read Phantom Read
Read Uncommitted Möglich Möglich Möglich
Read Committed Unmöglich Möglich Möglich
Repeatable Read Unmöglich Unmöglich Möglich
Serializable Unmöglich Unmöglich Unmöglich

Read Uncommitted

Bei dieser Transaktionsisolationsebene findet praktisch keine Isolation statt. Änderungen aus anderen Transaktionen sind sofort sichtbar, auch wenn diese noch nicht committed sind.

Read Committed

Im Unterschied zur vorhergehenden Ebene sind hier Änderungen einer parallel ablaufenden Transaktion erst nach einem commit sichtbar. Das bedeutet, dass Transaktionen lediglich vor Daten geschützt sind, die am Ende einer anderen Transaktion nicht übernommen werden. Solche Daten sind üblicherweise fehlerhaft (sonst würden sie ja am Ende der Transaktion committed werden). Diese Isolationsebene ist bei vielen Datenbanksystemen die Voreinstellung, da sie - nach dem vollständigen Fehlen jeder Isolation - am einfachsten zu implementieren ist.

Repeatable Read

Bei dieser Isolationsebene ist sichergestellt, dass wiederholte Leseoperationen mit den gleichen Parametern auch die selben Ergebnisse haben. Üblicherweise wird dies sichergestellt, indem eine Transaktion nur Daten sieht, die vor ihrem Startzeitpunkt vorhanden waren. Eine parallele Änderung führt somit auch nach commit nicht zu Inkonsistenzen während einer Transaktion. Dennoch ist es möglich, dass zwei Transaktionen parallel den selben Datensatz modifizieren und nach Ablauf dieser beiden Transaktionen nur die Änderungen von einer von ihnen übernommen wird. Soll die Isolationsebene nicht erhöht werden, können solche Probleme eventuell auch durch Locking umgangen werden.

Serializable

Die höchste Isolationsebene garantiert, dass die Wirkung parallel ablaufender Transaktionen exakt die selbe ist wie sie die entsprechenden Transaktionen zeigen würden, liefen sie nacheinander in Folge ab. Auf diese Weise ist sichergestellt, dass keine Transaktion verloren geht und dass sich keine zwei Transaktionen gegenseitig in die Quere kommen. Da die meisten Datenbanksysteme allerdings nur eine Illusion von sequentieller Ausführung aufrecht erhalten, ohne tatsächlich alle Transaktionen nacheinander einzeln abzuarbeiten, kann es hier vorkommen, dass eine Transaktion von der Seite der Datenbank aus abgebrochen werden muss. Eine Anwendung, die mit einer Datenbank arbeitet, bei der die Isolationsebene Serializable gewählt wurde, muss daher mit Serialisationsfehlern umgehen können und die entsprechende Transaktion gegebenenfalls neu beginnen.