it-swarm.com.de

Unterschied zwischen Read Commit und wiederholbarem Lesen

Ich denke die obigen Isolationsstufen sind so ähnlich. Könnte jemand bitte mit ein paar schönen Beispielen beschreiben, was der Hauptunterschied ist? 

194
Fore

Read Commited ist eine Isolationsstufe, die garantiert, dass alle gelesenen Daten zum Zeitpunkt Commited gelesen wurden. Es hindert den Leser einfach daran, zwischenzeitliche, nicht festgeschriebene "Dirty" -Lesen zu sehen. Die IT-Abteilung gibt keinerlei Versprechen ab, dass bei einer erneuten Ausgabe der Leseoperation durch die Transaktion die Daten Same gefunden werden und die Daten nach dem Lesen geändert werden können.

Repeatable Read ist eine höhere Isolationsstufe, die zusätzlich zu den Garantien der Read Commit-Stufe auch gewährleistet, dass alle gelesenen Daten können sich nicht ändern, wenn die Transaktion dieselben Daten erneut liest, sie die vorherigen finden Daten an Ort und Stelle lesen, unverändert und zum Lesen verfügbar.

Die nächste, serialisierbare Isolationsstufe bietet eine noch stärkere Garantie: Zusätzlich zu allen wiederholbaren Lesegarantien gewährleistet sie auch, dass keine neuen Daten durch ein nachfolgendes Lesen erkannt werden können.

Angenommen, Sie haben eine Tabelle T mit einer Spalte C und einer Zeile. Sagen Sie, sie hat den Wert '1'. Und bedenken Sie, dass Sie eine einfache Aufgabe wie die folgende haben:

BEGIN TRANSACTION;
SELECT * FROM T;
WAITFOR DELAY '00:01:00'
SELECT * FROM T;
COMMIT;

Dies ist eine einfache Aufgabe, bei der zwei Lesevorgänge von Tabelle T mit einer Verzögerung von 1 Minute ausgegeben werden. 

  • unter READ COMITTED kann das zweite SELECT any data zurückgeben. Eine gleichzeitige Transaktion kann den Datensatz aktualisieren, löschen und neue Datensätze einfügen. Bei der zweiten Auswahl werden immer die Daten neu angezeigt.
  • bei REPEATABLE READ werden beim zweiten SELECT garantiert die Zeilen angezeigt, bei denen zuerst unverändert ausgewählt wurde. Neue Zeilen können durch eine gleichzeitige Transaktion in dieser Minute hinzugefügt werden, aber die vorhandenen Zeilen können weder gelöscht noch geändert werden.
  • bei SERIALIZABLE-Lesevorgängen werden für die zweite Auswahl genau dieselben Zeilen wie für die erste Zeile angezeigt. Keine Zeile kann geändert oder gelöscht werden, und neue Zeilen können durch eine gleichzeitige Transaktion eingefügt werden.

Wenn Sie der oben genannten Logik folgen, können Sie schnell feststellen, dass SERIALIZABLE-Transaktionen, obwohl sie Ihnen das Leben leicht machen können, immer vollständig blockieren alle möglichen gleichzeitigen Vorgänge sind, da sie erfordern, dass niemand Änderungen vornehmen, löschen oder einfügen kann Reihe. Die standardmäßige Transaktionsisolationsstufe des .Net System.Transactions-Bereichs ist serialisierbar. Dies erklärt in der Regel die daraus resultierende schlechte Leistung.

Und schließlich gibt es noch die SNAPSHOT-Isolationsstufe. Die SNAPSHOT-Isolationsstufe bietet die gleichen Garantien wie die Serialisierung, jedoch nicht durch die gleichzeitige Änderung der Daten durch keine gleichzeitige Transaktion. Stattdessen wird jeder Leser gezwungen, seine eigene Version der Welt zu sehen (seine eigene Momentaufnahme). Dies macht es sehr einfach zu programmieren und ist sehr skalierbar, da gleichzeitige Updates nicht blockiert werden. Dieser Vorteil bringt jedoch einen Preis mit sich: zusätzlicher Serverressourcenverbrauch. 

Zusatz liest:

465
Remus Rusanu

Wiederholbares Lesen

Der Zustand der Datenbank wird vom Beginn der Transaktion an beibehalten. Wenn Sie einen Wert in session1 abrufen, aktualisieren Sie diesen Wert in session2. Wenn Sie ihn in session1 erneut abrufen, werden dieselben Ergebnisse zurückgegeben. Lesevorgänge sind wiederholbar.

session1> BEGIN;
session1> SELECT firstname FROM names WHERE id = 7;
Aaron

session2> BEGIN;
session2> SELECT firstname FROM names WHERE id = 7;
Aaron
session2> UPDATE names SET firstname = 'Bob' WHERE id = 7;
session2> SELECT firstname FROM names WHERE id = 7;
Bob
session2> COMMIT;

session1> SELECT firstname FROM names WHERE id = 7;
Aaron

Lesen Sie Committed

Im Kontext einer Transaktion rufen Sie immer den zuletzt festgeschriebenen Wert ab. Wenn Sie einen Wert in session1 abrufen, ihn in session2 aktualisieren und ihn in session1again abrufen, erhalten Sie den in session2 geänderten Wert. Es liest die letzte festgeschriebene Zeile.

session1> BEGIN;
session1> SELECT firstname FROM names WHERE id = 7;
Aaron

session2> BEGIN;
session2> SELECT firstname FROM names WHERE id = 7;
Aaron
session2> UPDATE names SET firstname = 'Bob' WHERE id = 7;
session2> SELECT firstname FROM names WHERE id = 7;
Bob
session2> COMMIT;

session1> SELECT firstname FROM names WHERE id = 7;
Bob

Macht Sinn?

57
Hazel_arun

Nach meinem einfachen Lesen und Verstehen auf diesen Thread und die Antwort von @ remus-rusanu basiert die einfache Antwort auf diesem einfachen Szenario:

Es gibt zwei Prozesse A und B. Prozess B liest Tabelle X Prozess A schreibt in Tabelle X Prozess B liest erneut Tabelle X.

  • ReadUncommitted : Prozess B kann nicht festgeschriebene Daten aus Prozess A lesen und basierend auf B-Schreiben andere Zeilen sehen. überhaupt keine Sperre
  • ReadCommitted : Prozess B kann NUR festgeschriebene Daten aus Prozess A lesen, und es können basierend auf COMMITTED nur B-Schreiben andere Zeilen angezeigt werden. könnten wir es Simple Lock nennen?
  • RepeatableRead : Prozess B liest die gleichen Daten (Zeilen), was Prozess A gerade tut. Prozess A kann jedoch andere Zeilen ändern. Zeilenebene Block
  • Serialisable : Prozess B liest die gleichen Zeilen wie zuvor und Prozess A kann nicht in die Tabelle lesen oder schreiben. Block auf Tabellenebene
  • Momentaufnahme : Jeder Prozess hat eine eigene Kopie und er arbeitet daran. Jeder hat seine eigene Sicht
14
Mo Zaatar

Alte Frage, die bereits eine akzeptierte Antwort hat, aber ich möchte an diese beiden Isolationsstufen denken, wie sie das Sperrverhalten in SQL Server ändern. Dies könnte für diejenigen hilfreich sein, die Deadlocks wie ich debuggen.

READ COMMITTED (Standardeinstellung)

Freigegebene Sperren werden in SELECT übernommen und dann freigegeben, wenn die SELECT-Anweisung abgeschlossen ist. Auf diese Weise kann das System gewährleisten, dass nicht festgeschriebene Daten fehlerhaft gelesen werden. Andere Transaktionen können die zugrunde liegenden Zeilen noch ändern, nachdem Ihre SELECT-Anweisung abgeschlossen ist und bevor Ihre Transaktion abgeschlossen ist.

REPEATABLE READ

Freigegebene Sperren werden in SELECT übernommen und erst dann freigegeben, wenn die Transaktion abgeschlossen ist. Auf diese Weise kann das System garantieren, dass sich die von Ihnen gelesenen Werte während der Transaktion nicht ändern (weil sie bis zum Abschluss der Transaktion gesperrt bleiben).

12
Chris Gillum

Versuchen, diesen Zweifel mit einfachen Diagrammen zu erklären. 

Read Committed: In dieser Isolationsstufe liest Transaktion T1 den aktualisierten Wert des von Transaktion T2 festgeschriebenen X. 

 Read Committed

Repeatable Read: In dieser Isolationsstufe berücksichtigt Transaktion T1 die von Transaktion T2 festgeschriebenen Änderungen nicht. 

 enter image description here

7
vkrishna17

Bitte beachten Sie, dass sich das repeatable in repeatable auf ein Tuple bezieht, jedoch nicht auf die gesamte Tabelle. In ANSC-Isolationsstufen kann Phantom Read Anomaly auftreten, was bedeutet, dass beim Lesen einer Tabelle mit derselben where-Klausel möglicherweise zwei unterschiedliche Ergebnismengen zurückgegeben werden. Wörtlich ist es nicht wiederholbar .

Ich denke, dieses Bild kann auch nützlich sein, es hilft mir als Referenz, wenn ich mich schnell an die Unterschiede zwischen den Isolationsstufen erinnern möchte (dank kudvenkat on youtube).

enter image description here

0
Ivan Pavičić