Parallelitätseffekte

Verlorene Aktualisierungen

Verlorene Aktualisierungen treten auf, wenn mindestens zwei Transaktionen dieselbe Zeile auswählen und diese Zeile dann auf der Grundlage des ursprünglich ausgewählten Werts aktualisieren. Eine einzelne Transaktion ist nicht über die anderen Transaktionen informiert. Die letzte Aktualisierung überschreibt Aktualisierungen von anderen Transaktionen; dies führt zu Datenverlusten.

Nehmen Sie beispielsweise an, dass zwei Redakteure eine elektronische Kopie desselben Dokuments erstellen. Jeder Redakteur ändert die eigene Kopie und speichert die geänderte Kopie anschließend, wodurch das Originaldokument überschrieben wird. Der Redakteur, der die Kopie zuletzt speichert, überschreibt die Änderungen des anderen Redakteurs. Das Problem könnte vermieden werden, wenn einer der Redakteure erst auf die Datei zugreifen kann, nachdem der andere Redakteur seine Arbeit beendet und ein Commit der Transaktion ausgeführt hat.

Abhängigkeit von Daten, für die kein Commit ausgeführt wurde (Dirty Read)

Die Abhängigkeit von Daten, für die kein Commit ausgeführt wurde, tritt dann ein, wenn eine zweite Transaktion eine Zeile auswählt, die von einer anderen Transaktion aktualisiert wird. Die zweite Transaktion liest Daten, für die noch kein Commit ausgeführt wurde und die von der Transaktion, die die Zeile aktualisiert, noch geändert werden können.

Angenommen, ein Redakteur nimmt Änderungen an einem elektronischen Dokument vor. Während die Änderungen vorgenommen werden, verteilt ein zweiter Redakteur eine Kopie des Dokuments mit allen bisherigen Änderungen an die Zielgruppe. Der erste Redakteur entscheidet dann, dass die bisherigen Änderungen falsch sind, löscht sie und speichert das Dokument. Das verteilte Dokument enthält nun Änderungen, die nicht mehr vorhanden sind und so behandelt werden müssten, als ob sie nie vorhanden gewesen wären. Dieses Problem könnte vermieden werden, wenn das geänderte Dokument erst dann gelesen werden könnte, wenn der erste Redakteur die endgültige Speicherung der Änderungen vorgenommen und ein Commit der Transaktion ausgeführt hat.

Inkonsistente Analyse (nicht wiederholbarer Lesevorgang)

Die inkonsistente Analyse tritt dann ein, wenn eine zweite Transaktion mehrmals auf dieselbe Zeile zugreift und jedes Mal verschiedene Daten liest. Die inkonsistente Analyse ist vergleichbar mit der Abhängigkeit von Daten, für die kein Commit ausgeführt wurde, da auch in diesem Fall eine andere Transaktion die Daten ändert, die eine zweite Transaktion liest. Bei der inkonsistenten Analyse wurde jedoch für die von der zweiten Transaktion gelesenen Daten ein Commit von der Transaktion, die die Änderung vornahm, ausgeführt. Darüber hinaus umfasst die inkonsistente Analyse mehrere Lesevorgänge (mindestens zwei) derselben Zeile, wobei jedes Mal die Informationen von einer anderen Transaktion geändert wurden; der Begriff "Nicht wiederholbarer Lesevorgang" bezieht sich auf diesen Vorgang.

Angenommen, ein Redakteur liest dasselbe Dokument zweimal, doch zwischen den einzelnen Lesedurchgängen schreibt der Verfasser das Dokument um. Wenn der Redakteur das Dokument zum zweiten Mal liest, unterscheidet es sich von der ersten Version. Der ursprüngliche Lesevorgang lässt sich nicht wiederholen. Dieses Problem könnte vermieden werden, wenn der Verfasser das Dokument erst ändern könnte, nachdem der Redakteur den letzten Lesevorgang beendet hat.

Phantomlesezugriffe

Ein Phantomlesezugriff tritt dann ein, wenn ein Einfügungs- oder Löschvorgang in einer Zeile vorgenommen wird, die zu einem Zeilenbereich gehört, der von einer Transaktion gelesen wird. Der erste Lesevorgang der Transaktion des Zeilenbereichs zeigt eine Zeile, die im zweiten Lesevorgang oder den nachfolgenden Lesevorgängen aufgrund einer Löschung durch eine andere Transaktion nicht mehr vorhanden ist. Als Folge einer Einfügung durch eine andere Transaktion zeigt der zweite Lesevorgang oder nachfolgende Lesevorgänge einer Transaktion eine Zeile an, die beim ursprünglichen Lesevorgang nicht vorhanden war.

So wäre es z. B. möglich, dass ein Redakteur Änderungen an einem Dokument eines Verfassers vornimmt. Von der Produktionsabteilung wird später beim Einfügen der Änderungen in die Hauptversion des Dokuments festgestellt, dass der Verfasser dem Dokument neues, unbearbeitetes Material hinzugefügt hat. Dieses Problem könnte ähnlich wie bei einem nicht wiederholbaren Lesevorgang vermieden werden, wenn neue Teile zu einem Dokument erst dann hinzugefügt werden können, wenn der Redakteur und die Produktionsabteilung die Bearbeitung der ursprünglichen Version des Dokuments abgeschlossen haben.

Durch Zeilenaktualisierungen verursachte fehlende und doppelte Lesezugriffe

• Übergehen einer aktualisierten Zeile oder mehrfaches Erkennen einer aktualisierten Zeile

  Transaktionen, die auf der READ UNCOMMITTED-Ebene ausgeführt werden, geben keine freigegebenen Sperren aus, die verhindern würden, dass andere Transaktionen Daten ändern, die von der aktuellen Transaktion gelesen werden. Transaktionen, die auf der READ COMMITTED-Ebene ausgeführt werden, geben freigegebene Sperren aus. Diese Zeilen- oder Seitensperren werden jedoch aufgehoben, nachdem die Zeile gelesen wurde. In beiden Fällen kann beim Scannen eines Index eine Zeile zwei Mal erscheinen, wenn ein anderer Benutzer die Indexschlüsselspalte ändert, während Sie sie lesen, und die Spalte durch die Schlüsseländerung an eine Position hinter der aktuellen Leseposition verschoben wird. Ebenso ist es möglich, dass die Zeile nicht erscheint, wenn die Spalte durch die Schlüsseländerung an eine Indexposition verschoben wird, die bereits gelesen wurde. Um dies zu vermeiden, verwenden Sie den SERIALISIERBARE- oder HOLDLOCK-Hinweis oder die Zeilenversionsverwaltung. Weitere Informationen finden Sie unter Tabellenhinweise (Transact-SQL) und unter Auf Zeilenversionsverwaltung basierende Isolationsstufen im Datenbankmodul.

• Übergehen von Zeilen, die nicht Ziel von Aktualisierungen waren

  Wenn READ UNCOMMITTED angegeben wird und eine Abfrage Zeilen in der Speicherreservierungsreihenfolge (unter Verwendung der IAM-Seiten) liest, werden möglicherweise Zeilen übergangen, falls eine Seite durch eine andere Transaktion geteilt wird. Dieser Fall kann beim Einsatz von READ UNCOMMITTED nicht eintreten, weil während der Teilung einer Seite eine Tabellensperre aufrechterhalten wird. Es werden auch keine Zeilen übergangen, wenn die Tabelle nicht über einen gruppierten Index verfügt, da Aktualisierungen keine Seitenteilungen verursachen.

Siehe auch

Konzepte