Vergleich der Isolationsstufen von Babelfish und SQL Server

PDFRSS

Im Folgenden finden Sie einige Beispiele für die Nuancen bei der Implementierung der Isolationsstufen durch SQL Server und Babelfish. ANSI

Anmerkung

• Isolationsstufe REPEATABLE READ und SNAPSHOT sind in Babelfish identisch.

• Isolationsstufe READ UNCOMMITTED und READ COMMITTED sind in Babelfish identisch.

Das folgende Beispiel zeigt, wie die Basistabelle für alle unten genannten Beispiele erstellt wird:

CREATE TABLE employee (
    id sys.INT NOT NULL PRIMARY KEY,
    name sys.VARCHAR(255)NOT NULL,
    age sys.INT NOT NULL
);
INSERT INTO employee (id, name, age) VALUES (1, 'A', 10);
INSERT INTO employee (id, name, age) VALUES (2, 'B', 20);
INSERT INTO employee (id, name, age) VALUES (3, 'C', 30);

Babelfish READ UNCOMMITTED im Vergleich zur SQL Serverisolationsstufe READ UNCOMMITTED

Die folgende Tabelle enthält Einzelheiten zu den Dirty Reads, wenn gleichzeitige Transaktionen ausgeführt werden. Sie zeigt die beobachteten Ergebnisse bei der Verwendung der READ UNCOMMITTED Isolationsstufe in SQL Server im Vergleich zur Babelfish-Implementierung.

Transaktion 1	Transaktion 2	SQLServer READ UNCOMMITTED	Babelfish READ UNCOMMITTED
BEGIN TRANSACTION	BEGIN TRANSACTION	Keine	Keine
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;	SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;	Keine	None
Leerlauf in Transaktion	UPDATE employee SET age=0;	Aktualisierung erfolgreich.	Aktualisierung erfolgreich.
Leerlauf in Transaktion	INSERT INTO employee VALUES (4, 'D', 40);	Das Einfügen war erfolgreich.	Das Einfügen war erfolgreich.
SELECT * FROM employee;	Leerlauf in Transaktion	Transaktion 1 kann noch nicht festgeschriebene Änderungen aus Transaktion 2 sehen.	Wie READ COMMITTED in Babelfish. Nicht festgeschriebene Änderungen aus Transaktion 2 sind für Transaktion 1 nicht sichtbar.
Leerlauf in Transaktion	COMMIT	Keine	None
SELECT * FROM employee;	Leerlauf in Transaktion	Sieht die von Transaktion 2 festgeschriebenen Änderungen.	Sieht die von Transaktion 2 festgeschriebenen Änderungen.

Babelfish READ COMMITTED im Vergleich zur SQL Serverisolationsstufe READ COMMITTED

Die folgende Tabelle enthält Einzelheiten zum Verhalten beim Blockieren von Lese- und Schreibvorgängen bei gleichzeitiger Ausführung von Transaktionen. Sie zeigt die beobachteten Ergebnisse bei der Verwendung der READ COMMITTED Isolationsstufe in SQL Server im Vergleich zur Babelfish-Implementierung.

Transaktion 1	Transaktion 2	SQLServer READ COMMITTED	Babelfish READ COMMITTED
BEGIN TRANSACTION	BEGIN TRANSACTION	Keine	Keine
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;	SET TRANSACTION ISOLATION LEVEL READ COMMITTED;	Keine	None
SELECT * FROM employee;	Leerlauf in Transaktion	Keine	None
Leerlauf in Transaktion	UPDATE employee SET age=100 WHERE id = 1;	Aktualisierung erfolgreich.	Aktualisierung erfolgreich.
UPDATE employee SET age = 0 WHERE age IN (SELECT MAX(age) FROM employee);	Leerlauf in Transaktion	Schritt blockiert, bis Transaktion 2 festgeschrieben wird.	Die Änderungen an Transaktion 2 sind noch nicht sichtbar. Aktualisiert die Zeile mit id=3.
Leerlauf in Transaktion	COMMIT	Transaktion 2 wird erfolgreich festgeschrieben. Transaktion 1 ist jetzt entsperrt und es erfolgt die Aktualisierung von Transaktion 2.	Transaktion 2 wird erfolgreich festgeschrieben.
SELECT * FROM employee;	Leerlauf in Transaktion	Transaktion 1 aktualisiert die Zeile mit der ID = 1.	Transaktion 1 aktualisiert die Zeile mit der ID = 3.

Babelfish READ COMMITTED im Vergleich zur SQL Serverisolationsstufe READ COMMITTED SNAPSHOT

Die folgende Tabelle enthält Einzelheiten zum Blockierungsverhalten der neu eingefügten Zeilen, wenn gleichzeitige Transaktionen ausgeführt werden. Sie zeigt die beobachteten Ergebnisse bei der Verwendung der READ COMMITTED SNAPSHOT Isolationsstufe in SQL Server im Vergleich zur READ COMMITTED Babelfish-Implementierung.

Transaktion 1	Transaktion 2	SQLServer READ COMMITTED SNAPSHOT	Babelfish READ COMMITTED
BEGIN TRANSACTION	BEGIN TRANSACTION	Keine	Keine
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;	SET TRANSACTION ISOLATION LEVEL READ COMMITTED;	Keine	None
INSERT INTO employee VALUES (4, 'D', 40);	Leerlauf in Transaktion	Keine	None
Leerlauf in Transaktion	UPDATE employee SET age = 99;	Der Schritt ist blockiert, bis Transaktion 1 festgeschrieben wird. Die eingefügte Zeile ist durch Transaktion 1 gesperrt.	Drei Zeilen wurden aktualisiert. Die neu eingefügte Zeile ist noch nicht sichtbar.
COMMIT	Leerlauf in Transaktion	Der Commit war erfolgreich. Transaktion 2 ist jetzt entsperrt.	Der Commit war erfolgreich.
Leerlauf in Transaktion	SELECT * FROM employee;	Alle 4 Zeilen haben Alter=99.	Die Zeile mit der ID = 4 hat den Alterswert 40, da sie während der Aktualisierungsabfrage für Transaktion 2 nicht sichtbar war. Andere Zeilen werden auf Alter=99 aktualisiert.

Babelfish REPEATABLE READ im Vergleich zur Serverisolationsstufe SQL REPEATABLE READ

Die folgende Tabelle enthält Einzelheiten zum Verhalten beim Blockieren von Lese- und Schreibvorgängen bei gleichzeitiger Ausführung von Transaktionen. Sie zeigt die beobachteten Ergebnisse bei der Verwendung der REPEATABLE READ Isolationsstufe in SQL Server im Vergleich zur Babelfish-Implementierung. REPEATABLE READ

Transaktion 1	Transaktion 2	SQLServer REPEATABLE READ	Babelfish REPEATABLE READ
BEGIN TRANSACTION	BEGIN TRANSACTION	Keine	Keine
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;	SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;	Keine	None
SELECT * FROM employee;	Leerlauf in Transaktion	Keine	None
UPDATE employee SET name='A_TXN1' WHERE id=1;	Leerlauf in Transaktion	Keine	None
Leerlauf in Transaktion	SELECT * FROM employee WHERE id != 1;	Keine	None
Leerlauf in Transaktion	SELECT * FROM employee;	Transaktion 2 ist blockiert, bis Transaktion 1 festgeschrieben wird.	Transaktion 2 läuft normal ab.
COMMIT	Leerlauf in Transaktion	Keine	None
Leerlauf in Transaktion	SELECT * FROM employee;	Das Update von Transaktion 1 ist sichtbar.	Das Update von Transaktion 1 ist nicht sichtbar.
COMMIT	Leerlauf in Transaktion	Keine	None
Leerlauf in Transaktion	SELECT * FROM employee;	sieht das Update von Transaktion 1.	sieht das Update von Transaktion 1.

Die folgende Tabelle enthält Einzelheiten zum Verhalten beim Blockieren von Schreib- und Schreibvorgängen bei gleichzeitiger Ausführung von Transaktionen. Sie zeigt die beobachteten Ergebnisse bei der Verwendung der REPEATABLE READ Isolationsstufe in SQL Server im Vergleich zur Babelfish-Implementierung. REPEATABLE READ

Transaktion 1	Transaktion 2	SQLServer REPEATABLE READ	Babelfish REPEATABLE READ
BEGIN TRANSACTION	BEGIN TRANSACTION	Keine	Keine
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;	SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;	Keine	None
UPDATE employee SET name='A_TXN1' WHERE id=1;	Leerlauf in Transaktion	Keine	None
Leerlauf in Transaktion	UPDATE employee SET name='A_TXN2' WHERE id=1;	Transaktion 2 blockiert.	Transaktion 2 wurde blockiert.
COMMIT	Leerlauf in Transaktion	Die Übertragung war erfolgreich und Transaktion 2 wurde entsperrt.	Die Übertragung war erfolgreich und Transaktion 2 schlägt fehl. Der Zugriff konnte aufgrund der gleichzeitigen Aktualisierung nicht serialisiert werden.
Leerlauf in Transaktion	COMMIT	Der Commit war erfolgreich.	Transaktion 2 wurde bereits abgebrochen.
Leerlauf in Transaktion	SELECT * FROM employee;	Zeile mit ID=1 hat Name='A_ '. TX2	Zeile mit ID=1 hat Name='A_ '. TX1

Die folgende Tabelle enthält Einzelheiten zum Verhalten von Phantomlesevorgängen bei der Ausführung gleichzeitiger Transaktionen. Sie zeigt die beobachteten Ergebnisse bei der Verwendung der REPEATABLE READ Isolationsstufe in SQL Server im Vergleich zur REPEATABLE READ Babelfish-Implementierung.

Transaktion 1	Transaktion 2	SQLServer REPEATABLE READ	Babelfish REPEATABLE READ
BEGIN TRANSACTION	BEGIN TRANSACTION	Keine	Keine
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;	SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;	Keine	None
SELECT * FROM employee;	Leerlauf in Transaktion	Keine	None
Leerlauf in Transaktion	INSERT INTO employee VALUES (4, 'NewRowName', 20);	Transaktion 2 läuft ohne jegliche Blockierung ab.	Transaktion 2 wird ohne jegliche Blockierung fortgesetzt.
Leerlauf in Transaktion	SELECT * FROM employee;	Die neu eingefügte Zeile ist sichtbar.	Die neu eingefügte Zeile ist sichtbar.
Leerlauf in Transaktion	COMMIT	Keine	None
SELECT * FROM employee;	Leerlauf in Transaktion	Die von Transaktion 2 eingefügte neue Zeile ist sichtbar.	Die von Transaktion 2 eingefügte neue Zeile ist nicht sichtbar.
COMMIT	Leerlauf in Transaktion	Keine	None
SELECT * FROM employee;	Leerlauf in Transaktion	Die neu eingefügte Zeile ist sichtbar.	Die neu eingefügte Zeile ist sichtbar.

Die folgende Tabelle enthält Informationen darüber, wann gleichzeitige Transaktionen ausgeführt werden und welche unterschiedlichen Endergebnisse bei Verwendung der REPEATABLE READ Isolationsstufe in SQL Server im Vergleich zur REPEATABLE READ Babelfish-Implementierung erzielt werden.

Transaktion 1	Transaktion 2	SQLServer REPEATABLE READ	Babelfish REPEATABLE READ
BEGIN TRANSACTION	BEGIN TRANSACTION	Keine	Keine
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;	SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;	Keine	None
UPDATE employee SET age = 100 WHERE age IN (SELECT MIN(age) FROM employee);	Leerlauf in Transaktion	Transaktion 1 aktualisiert die Zeile mit der ID 1.	Transaktion 1 aktualisiert die Zeile mit der ID 1.
Leerlauf in Transaktion	UPDATE employee SET age = 0 WHERE age IN (SELECT MAX(age) FROM employee);	Transaktion 2 ist blockiert, da die SELECT Anweisung versucht, Zeilen zu lesen, die durch die UPDATE Abfrage in Transaktion 1 gesperrt wurden.	Transaktion 2 wird ohne Blockierung fortgesetzt, da der Lesevorgang nie blockiert wird, die SELECT Anweisung ausgeführt wird und schließlich die Zeile mit der ID = 3 aktualisiert wird, da die Änderungen in Transaktion 1 noch nicht sichtbar sind.
Leerlauf in Transaktion	SELECT * FROM employee;	Dieser Schritt wird ausgeführt, nachdem Transaktion 1 festgeschrieben wurde. Die Zeile mit der ID = 1 wurde durch Transaktion 2 im vorherigen Schritt aktualisiert und ist hier sichtbar.	Die Zeile mit der ID = 3 wird durch Transaktion 2 aktualisiert.
COMMIT	Leerlauf in Transaktion	Transaktion 2 ist jetzt entsperrt.	Der Commit war erfolgreich.
Leerlauf in Transaktion	COMMIT	Keine	None
SELECT * FROM employee;	Leerlauf in Transaktion	Beide Transaktionen führen das Update für die Zeile mit der ID = 1 aus.	Verschiedene Zeilen werden durch Transaktion 1 und 2 aktualisiert.

Babelfish SERIALIZABLE im Vergleich zur SQL Serverisolationsstufe SERIALIZABLE

Die folgende Tabelle enthält Einzelheiten zu den Bereichssperren, wenn gleichzeitige Transaktionen ausgeführt werden. Sie zeigt die beobachteten Ergebnisse bei der Verwendung der SERIALIZABLE Isolationsstufe in SQL Server im Vergleich zur SERIALIZABLE Babelfish-Implementierung.

Transaktion 1	Transaktion 2	SQLServer SERIALIZABLE	Babelfish SERIALIZABLE
BEGIN TRANSACTION	BEGIN TRANSACTION	Keine	Keine
SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;	SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;	Keine	None
SELECT * FROM employee;	Leerlauf in Transaktion	Keine	None
Leerlauf in Transaktion	INSERT INTO employee VALUES (4, 'D', 35);	Transaktion 2 ist blockiert, bis Transaktion 1 festgeschrieben wird.	Transaktion 2 wird ohne Blockierung fortgesetzt.
Leerlauf in Transaktion	SELECT * FROM employee;	Keine	None
COMMIT	Leerlauf in Transaktion	Transaktion 1 wird erfolgreich festgeschrieben. Transaktion 2 ist jetzt entsperrt.	Transaktion 1 wird erfolgreich festgeschrieben.
Leerlauf in Transaktion	COMMIT	Keine	None
SELECT * FROM employee;	Leerlauf in Transaktion	Die neu eingefügte Zeile ist sichtbar.	Die neu eingefügte Zeile ist sichtbar.

Die folgende Tabelle enthält Informationen darüber, wann gleichzeitige Transaktionen ausgeführt werden und welche unterschiedlichen Endergebnisse bei Verwendung der SERIALIZABLE Isolationsstufe in SQL Server im Vergleich zur SERIALIZABLE Babelfish-Implementierung erzielt werden.

Transaktion 1	Transaktion 2	SQLServer SERIALIZABLE	Babelfish SERIALIZABLE
BEGIN TRANSACTION	BEGIN TRANSACTION	Keine	Keine
SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;	SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;	Keine	None
Leerlauf in Transaktion	INSERT INTO employee VALUES (4, 'D', 40);	Keine	None
UPDATE employee SET age =99 WHERE id = 4;	Leerlauf in Transaktion	Transaktion 1 ist blockiert, bis Transaktion 2 festgeschrieben wird.	Transaktion 1 wird ohne Blockierung fortgesetzt.
Leerlauf in Transaktion	COMMIT	Transaktion 2 wird erfolgreich festgeschrieben. Transaktion 1 ist jetzt entsperrt.	Transaktion 2 wird erfolgreich festgeschrieben.
COMMIT	Leerlauf in Transaktion	Keine	None
SELECT * FROM employee;	Leerlauf in Transaktion	Die neu eingefügte Zeile ist mit einem Alterswert von 99 sichtbar.	Die neu eingefügte Zeile ist mit dem Alterswert = 40 sichtbar.

Die folgende Tabelle enthält Einzelheiten, wenn Sie INSERT eine Tabelle mit eindeutiger Einschränkung aufrufen. Sie zeigt die beobachteten Ergebnisse bei der Verwendung der SERIALIZABLE Isolationsstufe in SQL Server im Vergleich zur SERIALIZABLE Babelfish-Implementierung.

Transaktion 1	Transaktion 2	SQLServer SERIALIZABLE	Babelfish SERIALIZABLE
BEGIN TRANSACTION	BEGIN TRANSACTION	Keine	Keine
SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;	SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;	Keine	None
Leerlauf in Transaktion	INSERT INTO employee VALUES (4, 'D', 40);	Keine	None
INSERT INTO employee VALUES ((SELECT MAX(id)+1 FROM employee), 'E', 50);	Leerlauf in Transaktion	Transaktion 1 ist blockiert, bis Transaktion 2 festgeschrieben wird.	Transaktion 1 ist blockiert, bis Transaktion 2 festgeschrieben wird.
Leerlauf in Transaktion	COMMIT	Transaktion 2 wird erfolgreich festgeschrieben. Transaktion 1 ist jetzt entsperrt.	Transaktion 2 wird erfolgreich festgeschrieben. Transaktion 1 wurde mit dem Fehler „Doppelter Schlüsselwert verletzt eindeutige Einschränkung“ abgebrochen.
COMMIT	Leerlauf in Transaktion	Transaktion 1 wird erfolgreich festgeschrieben.	Transaktion 1 schlägt fehl, da der Zugriff aufgrund von Lese- oder Schreibabhängigkeiten zwischen den Transaktionen nicht serialisiert werden konnte.
SELECT * FROM employee;	Leerlauf in Transaktion	Zeile (5, 'E', 50) wird eingefügt.	Es sind nur 4 Zeilen vorhanden.

In Babelfish schlagen gleichzeitige Transaktionen, die mit der Isolationsstufe serializable ausgeführt werden, mit einem Fehler bei der Serialisierungsanomalie fehl, wenn die Ausführung dieser Transaktionen nicht mit allen möglichen seriellen (nacheinander) Ausführungen dieser Transaktionen übereinstimmt.

Die folgenden Tabellen enthalten Einzelheiten zur Serialisierungsanomalie bei der Ausführung gleichzeitiger Transaktionen. Sie zeigt die beobachteten Ergebnisse bei der Verwendung der SERIALIZABLE Isolationsstufe in SQL Server im Vergleich zur Babelfish-Implementierung. SERIALIZABLE

Transaktion 1	Transaktion 2	SQLServer SERIALIZABLE	Babelfish SERIALIZABLE
BEGIN TRANSACTION	BEGIN TRANSACTION	Keine	Keine
SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;	SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;	Keine	None
SELECT * FROM employee;	Leerlauf in Transaktion	Keine	None
UPDATE employee SET age=5 WHERE age=10;	Leerlauf in Transaktion	Keine	None
Leerlauf in Transaktion	SELECT * FROM employee;	Transaktion 2 ist blockiert, bis Transaktion 1 festgeschrieben wird.	Transaktion 2 wird ohne Blockierung fortgesetzt.
Leerlauf in Transaktion	UPDATE employee SET age=35 WHERE age=30;	Keine	None
COMMIT	Leerlauf in Transaktion	Transaktion 1 wird erfolgreich festgeschrieben.	Transaktion 1 wird zuerst festgeschrieben und kann erfolgreich festgeschrieben werden.
Leerlauf in Transaktion	COMMIT	Transaktion 2 wird erfolgreich festgeschrieben.	Die Übertragung von Transaktion 2 schlägt mit einem Serialisierungsfehler fehl. Die gesamte Transaktion wurde zurückgesetzt. Versuchen Sie Transaktion 2 erneut.
SELECT * FROM employee;	Leerlauf in Transaktion	Änderungen aus beiden Transaktionen sind sichtbar.	Transaktion 2 wurde rückgängig gemacht. Es werden nur Änderungen an Transaktion 1 angezeigt.

In Babelfish ist eine Serialisierungsanomalie nur möglich, wenn alle gleichzeitigen Transaktionen auf Isolationsebene ausgeführt werden. SERIALIZABLE In der folgenden Tabelle nehmen wir das obige Beispiel, setzen aber stattdessen Transaktion 2 auf Isolationsstufe. REPEATABLE READ

Transaktion 1	Transaktion 2	SQLIsolationsstufen für Server	Isolationsstufen für Babelfish
BEGIN TRANSACTION	BEGIN TRANSACTION	Keine	Keine
SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;	SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;	Keine	None
SELECT * FROM employee;	Leerlauf in Transaktion	Keine	None
UPDATE employee SET age=5 WHERE age=10;	Leerlauf in Transaktion	Keine	None
Leerlauf in Transaktion	SELECT * FROM employee;	Transaktion 2 ist blockiert, bis Transaktion 1 festgeschrieben wird.	Transaktion 2 wird ohne Blockierung fortgesetzt.
Leerlauf in Transaktion	UPDATE employee SET age=35 WHERE age=30;	Keine	None
COMMIT	Leerlauf in Transaktion	Transaktion 1 wird erfolgreich festgeschrieben.	Transaktion 1 wird erfolgreich festgeschrieben.
Leerlauf in Transaktion	COMMIT	Transaktion 2 wird erfolgreich festgeschrieben.	Transaktion 2 wird erfolgreich festgeschrieben.
SELECT * FROM employee;	Leerlauf in Transaktion	Änderungen aus beiden Transaktionen sind sichtbar.	Änderungen aus beiden Transaktionen sind sichtbar.