Quelltext der Seite Isolation (Datenbank)

In der [[Informatik]] bezeichnet der Begriff '''Isolation''' die Trennung von [[Transaktion (Informatik)|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 (Informatik)|ACID]]-Eigenschaften.

== 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:

{| class="wikitable"
|-
! class="hintergrundfarbe6"| Zeitpunkt
! class="hintergrundfarbe6"| Transaktion 1
! class="hintergrundfarbe6"| Transaktion 2
! class="hintergrundfarbe6"| 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:

{| class="wikitable"
|-
! class="hintergrundfarbe6"| Zeitpunkt
! class="hintergrundfarbe6"| Transaktion 1
! class="hintergrundfarbe6"| Transaktion 2
! class="hintergrundfarbe6"| Ergebnis
|-
| 1
| Aktion 1
|
| Keine Einträge gefunden.
|-
| 2
|
| style="color: gray" | [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 ([[Anomalie (Informatik)#Anomalien im Mehrbenutzerbetrieb|Anomalien]]) auftreten:
# '''[[Schreib-Lese-Konflikt|Dirty Read]]''': Daten einer noch nicht abgeschlossenen Transaktion werden von einer anderen Transaktion gelesen.
# '''[[Verlorene Updates|Lost Updates]]''': Zwei Transaktionen modifizieren parallel denselben Datensatz und nach Ablauf dieser beiden Transaktionen wird nur die Änderung von einer von ihnen übernommen.
# '''[[Nichtwiederholbares Lesen|Non-Repeatable Read]]''': Wiederholte Lesevorgänge liefern unterschiedliche Ergebnisse.
# '''[[Phantomproblem|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 (SQL-92) des Datenbankinterface [[SQL]] sieht vier Transaktionsisolationsebenen vor, die allerdings nicht alle von sämtlichen Datenbanksystemen unterstützt werden.<br />
Die folgende Tabelle<ref>http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt, S. 69</ref> gibt eine Übersicht über die Güte und die auftretenden Probleme bei Einsatz der verschiedenen Isolationsebenen:

{| class="wikitable"
|-
! class="hintergrundfarbe6"| Isolationsebene
! class="hintergrundfarbe6"| Dirty Read
! class="hintergrundfarbe6"| Lost Updates<ref>http://research.microsoft.com/apps/pubs/default.aspx?id=69541, S. 7</ref>
! class="hintergrundfarbe6"| Non-Repeatable Read
! class="hintergrundfarbe6"| Phantom Read
|-
| ''Read Uncommitted''
| style="color: #900030" | möglich
| style="color: #CAB727" | möglich auch bei Db2 CS
| style="color: #900030" | möglich
| style="color: #900030" | möglich
|-
| ''Read Committed''
| style="color: #308000" | unmöglich
| style="color: #CAB727" | möglich auch bei Db2 CS
| style="color: #900030" | möglich
| style="color: #900030" | möglich
|-
| ''Repeatable Read''
| style="color: #308000" | unmöglich
| style="color: #308000" | unmöglich
| style="color: #308000" | unmöglich
| style="color: #900030" | möglich
|-
| ''Serializable''
| style="color: #308000" | unmöglich
| style="color: #308000" | unmöglich
| style="color: #308000" | unmöglich
| style="color: #308000" | unmöglich
|}

=== Read Uncommitted ===
Bei dieser Isolationsebene ignorieren Leseoperationen jegliche Sperren, deshalb können die Anomalien Lost Update, Dirty Read, Non-Repeatable Read und das Phantom-Problem auftreten.
Der SQL-92-Standard spezifiziert zwar, dass bei jeder Isolationsebene eine Transaktion entweder vollständig oder gar nicht ausgeführt wird und keine Updates verloren gehen dürfen<ref>http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt, S. 68</ref>, jedoch scheint dies je nach [[Implementierung]] bzw. [[Sperrverfahren]] bei Read Uncommitted nicht immer gewährleistet zu sein. In jedem Fall verhindert werden so genannte Dirty Writes<ref>http://research.microsoft.com/apps/pubs/default.aspx?id=69541, S. 5</ref>, jedoch können Lost Updates trotz dieser Einschränkung immer noch auftreten. Deshalb ist in den meisten [[DBMS]] eine Isolationsebene implementiert, deren Sperrverhalten alle Lost Updates verhindert und damit mehr Schutz als das Read Uncommitted des SQL-92-Standards bietet<ref>http://research.microsoft.com/apps/pubs/default.aspx?id=69541, S. 7</ref>.

=== Read Committed ===
Diese Isolationsebene setzt für die gesamte Transaktion Schreibsperren auf Objekten, die verändert werden sollen, setzt Lesesperren aber nur kurzzeitig beim tatsächlichen Lesen der Daten ein. Daher können Non-Repeatable Read und Phantom Read auftreten, wenn während wiederholten Leseoperationen auf dieselben Daten, zwischen der ersten und der zweiten Leseoperation, eine Schreiboperation einer anderen Transaktion die Daten verändert und committed. Unter [[DB2]] beispielsweise wird diese Isolationsebene als Cursor Stability (CS) bezeichnet<ref>http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_72/db2/rbafzcursorstability.htm</ref>.

=== Repeatable Read ===
Bei dieser Isolationsebene ist sichergestellt, dass wiederholte Leseoperationen mit den gleichen Parametern auch dieselben Ergebnisse haben. Sowohl bei Lese- als auch bei Schreiboperationen werden für die gesamte Dauer der Transaktion Sperren gesetzt. Dies führt dazu, dass bis auf Phantom Reads keine Anomalien auftreten können.

=== Serializable ===
Die höchste Isolationsebene garantiert, dass die Wirkung parallel ablaufender Transaktionen exakt dieselbe 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 beeinflussen. Da die meisten Datenbanksysteme allerdings nur eine ''Illusion'' von sequentieller Ausführung aufrechterhalten, 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.

== MVCC ==
MVCC (Multi Version Concurrency Control) sorgt über Versionsbildung für möglichst geringe Wartezeiten. Durch Versionssprünge können "Lost Updates" auftreten, welche sich mit "select … for update" oder dem Sperren der Daten verhindern lassen. Leseoperationen verursachen niemals Wartezeiten, weil Schreiboperationen und Leseoperationen nicht auf dieselbe Version zugreifen. Um mehrere Versionen speichern zu können, ist folglich wesentlich mehr Arbeitsspeicher nötig. Der "Dirty Read" kann nicht auftreten, da Schreiboperationen nur nach einem "[[commit]]" eine den Leseoperationen zugängliche Version erzeugen.

{| class="wikitable"
|-
! class="hintergrundfarbe6"| Isolationsebene
! class="hintergrundfarbe6"| Dirty Read
! class="hintergrundfarbe6"| Non-Repeatable Read
! class="hintergrundfarbe6"| Phantom Read
! class="hintergrundfarbe6"| Lost Updates{{FN|1}}
|-
| ''Read Committed''
| style="color: #308000" | unmöglich
| style="color: #900030" | möglich
| style="color: #900030" | möglich
| style="color: #900030" | möglich
|-
| ''Repeatable Read''
| style="color: #308000" | unmöglich
| style="color: #308000" | unmöglich
| style="color: #900030" | möglich
| style="color: #900030" | möglich
|-
| ''Serializable''
| style="color: #308000" | unmöglich
| style="color: #308000" | unmöglich
| style="color: #308000" | unmöglich
| style="color: #900030" | möglich
|}

{{FNZ|1|Kann auftreten, wenn eine Transaktion mit einer Leseoperation beginnt und später eine Schreiboperation durchführt. Wenn zwischen den beiden Operationen eine Transaktion eine Schreiboperation durchführt, greift diese auf dieselbe Version zu wie die erste. Deshalb geht eine der Schreibaktionen verloren.}}

== Einzelnachweise ==
<references />

== Weblinks ==
* {{Internetquelle
   |hrsg=PostgreSQL
   |url=http://www.postgresql.org/docs/current/static/transaction-iso.html
   |sprache=en
   |titel=Transaction Isolation
   |werk=Dokumentation zu [[PostgreSQL]]
   |zugriff=2011-10-15}}
* {{Internetquelle
   |hrsg=MySQL
   |url=http://dev.mysql.com/doc/refman/5.6/en/innodb-transaction-model.html
   |sprache=en
   |titel=The InnoDB Transaction Model and Locking
   |werk=Dokumentation zu [[MySQL]]
   |zugriff=2011-10-15}}
*{{Internetquelle
   |hrsg=Oracle.com
   |url=https://docs.oracle.com/en/database/oracle/oracle-database/19/cncpt/data-concurrency-and-consistency.html
   |sprache=en
   |titel=Data Concurrency and Consistency
   |werk=Dokumentation zu [[Oracle (Datenbanksystem)|Oracle Datenbank]] Release 19
   |zugriff=2019-10-10|autor=|datum=}}
* {{Internetquelle
   |hrsg=Microsoft.com
   |url=http://research.microsoft.com/apps/pubs/default.aspx?id=69541
   |sprache=en
   |titel=A Critique of ANSI SQL Isolation Levels
   |zugriff=2012-04-26}}

{{Normdaten|TYP=s|GND=4704495-0}}

[[Kategorie:Datenbanktheorie]]