Um Transaktionen gleichzeitig zu bearbeiten, muss der Datenbankserver einige Teile der Anweisungen einer Transaktion ausführen, danach Teile von anderen Transaktionen, bevor wieder weitere Vorgänge von der ersten Transaktion durchgeführt werden. Die Reihenfolge, in der die Abläufe der verschiedenen Transaktionen miteinander verwoben sind, nennt sich Abfolgeplanung.
Wenn Transaktionen auf diese Art gleichzeitig durchgeführt werden, kann dies zu verschiedenen Ergebnissen führen, darunter auch zu den drei Inkonsistenzen, die im vorherigen Abschnitt beschrieben wurden. Manchmal wäre der endgültige Zustand der Datenbank auch erreicht worden, wenn die Transaktionen sequenziell durchgeführt worden wären, das heißt, dass eine Transaktion immer vollständig abgeschlossen wird, bevor die nächste beginnt. Eine Abfolgeplanung wird als serialisierbar bezeichnet, wenn die sequenzielle Ausführung der Transaktionen in einer beliebigen Reihenfolge zum gleichen Zustand der Datenbank geführt hätte.
Serialisierbarkeit ist das allgemein akzeptierte Kriterium für Fehlerfreiheit. Ein serialisierbares Schema wird als fehlerfrei akzeptiert, da die Datenbank nicht durch die gleichzeitige Ausführung der Transaktionen beeinträchtigt wird.
Die Isolationsstufe wirkt sich auf die Serialisierbarkeit einer Transaktion aus. Bei Isolationsstufe 3 sind alle Ablaufplanungen serialisierbar. Die Standardeinstellung ist 0.
Selbst wenn Transaktionen sequenziell ausgeführt werden, kann der endgültige Zustand der Datenbank von der Reihenfolge abhängen, in der diese Transaktionen durchgeführt werden. Beispiel: Wenn eine Transaktion eine bestimmte Zelle auf den Wert 5 setzt, und eine andere auf 6, wird der endgültige Wert der Zelle dadurch bestimmt, welche Transaktion zuletzt durchgeführt wird.
Das Wissen um die Serialisierbarkeit eines Schemas löst die Frage nicht, in welcher Reihenfolge die Transaktionen am besten ausgeführt werden, sondern gibt nur an, dass Parallelität keine Auswirkung hat. Die durch die sequenzielle Ausführung einer Reihe von Transaktionen erzielten Ergebnisse gelten alle als richtig.
Die unter Typische Arten von Inkonsistenz angeführten Inkonsistenzen sind typisch für Probleme, die auftreten, wenn der Zeitplan nicht serialisierbar ist. In jedem Fall kam es zu einer Inkonsistenz, da sich die Anweisungen überlappten. Das erzeugte Ergebnis wäre nicht möglich, wenn alle Transaktionen sequenziell ausgeführt worden wären. So kann zum Beispiel ein Dirty Read nur auftreten, wenn eine Transaktion Zeilen selektieren kann, während eine andere Transaktion in derselben Zeile Daten einfügt oder aktualisiert.
Kommentieren Sie diese Seite in DocCommentXchange. Senden Sie uns Feedback über diese Seite via E-Mail. |
Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1 |