Die Isolationsstufe READ UNCOMMITTED in Babelfish im Vergleich zur Isolationsstufe READ UNCOMMITTED in SQL Server Die Isolationsstufe READ COMMITTED in Babelfish im Vergleich zur Isolationsstufe READ COMMITTED in SQL Server Die Isolationsstufe READ COMMITTED in Babelfish im Vergleich zur Isolationsstufe READ COMMITTED SNAPSHOT in SQL Server Die Isolationsstufe REPEATABLE READ in Babelfish im Vergleich zur Isolationsstufe REPEATABLE READ in SQL Server Die Isolationsstufe SERIALIZABLE in Babelfish im Vergleich zur Isolationsstufe SERIALIZABLE in SQL Server

Vergleich der Isolationsstufen in Babelfish und SQL Server

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

Anmerkung

Die Isolationsstufen REPEATABLE READ und SNAPSHOT sind in Babelfish identisch.
Die Isolationsstufen READ UNCOMMITTED und READ COMMITTED sind in Babelfish identisch.

Im folgenden Beispiel wird gezeigt, 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);

Themen

Die Isolationsstufe READ UNCOMMITTED in Babelfish im Vergleich zur Isolationsstufe READ UNCOMMITTED in SQL Server
Die Isolationsstufe READ COMMITTED in Babelfish im Vergleich zur Isolationsstufe READ COMMITTED in SQL Server
Die Isolationsstufe READ COMMITTED in Babelfish im Vergleich zur Isolationsstufe READ COMMITTED SNAPSHOT in SQL Server
Die Isolationsstufe REPEATABLE READ in Babelfish im Vergleich zur Isolationsstufe REPEATABLE READ in SQL Server
Die Isolationsstufe SERIALIZABLE in Babelfish im Vergleich zur Isolationsstufe SERIALIZABLE in SQL Server

Die Isolationsstufe `READ UNCOMMITTED` in Babelfish im Vergleich zur Isolationsstufe `READ UNCOMMITTED` in SQL Server

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

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

Die Isolationsstufe `READ COMMITTED` in Babelfish im Vergleich zur Isolationsstufe `READ COMMITTED` in SQL Server

Die folgende Tabelle enthält Details zum Verhalten beim Blockieren von Lese-/Schreibvorgängen, wenn gleichzeitige Transaktionen ausgeführt werden. Sie zeigt die beobachteten Ergebnisse bei der Verwendung der Isolationsstufe READ COMMITTED in SQL Server im Vergleich zur Babelfish-Implementierung.

Transaktion 1	Transaktion 2	`READ COMMITTED` in SQL Server	`READ COMMITTED` in Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Keine	Keine
`SET TRANSACTION ISOLATION LEVEL READ COMMITTED;`	`SET TRANSACTION ISOLATION LEVEL READ COMMITTED;`	Keine	Keine
`SELECT * FROM employee;`	Leerlauf in Transaktion	Keine	Keine
Leerlauf in Transaktion	`UPDATE employee SET age=100 WHERE id = 1;`	Update erfolgreich	Update erfolgreich
`UPDATE employee SET age = 0 WHERE age IN (SELECT MAX(age) FROM employee);`	Leerlauf in Transaktion	Der Schritt ist 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 nicht mehr blockiert und sieht das Update von Transaktion 2.	Transaktion 2 wird erfolgreich festgeschrieben.
`SELECT * FROM employee;`	Leerlauf in Transaktion	Transaktion 1 aktualisiert die Zeile mit id = 1.	Transaktion 1 aktualisiert die Zeile mit id = 3.

Die Isolationsstufe `READ COMMITTED` in Babelfish im Vergleich zur Isolationsstufe `READ COMMITTED SNAPSHOT` in SQL Server

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

Transaktion 1	Transaktion 2	`READ COMMITTED SNAPSHOT` in SQL Server	`READ COMMITTED` in Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Keine	Keine
`SET TRANSACTION ISOLATION LEVEL READ COMMITTED;`	`SET TRANSACTION ISOLATION LEVEL READ COMMITTED;`	Keine	Keine
`INSERT INTO employee VALUES (4, 'D', 40);`	Leerlauf in Transaktion	Keine	Keine
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	Festschreiben erfolgreich. Transaktion 2 ist jetzt nicht mehr blockiert.	Festschreiben erfolgreich
Leerlauf in Transaktion	`SELECT * FROM employee;`	Alle 4 Zeilen haben age=99.	Die Zeile mit id = 4 hat den Age-Wert 40, da sie während der Update-Abfrage für Transaktion 2 nicht sichtbar war. Andere Zeilen werden auf age=99 aktualisiert.

Die Isolationsstufe `REPEATABLE READ` in Babelfish im Vergleich zur Isolationsstufe `REPEATABLE READ` in SQL Server

Die folgende Tabelle enthält Details zum Verhalten beim Blockieren von Lese-/Schreibvorgängen, wenn gleichzeitige Transaktionen ausgeführt werden. Sie zeigt die beobachteten Ergebnisse bei der Verwendung der Isolationsstufe REPEATABLE READ in SQL Server im Vergleich zur REPEATABLE READ-Babelfish-Implementierung.

Transaktion 1	Transaktion 2	`REPEATABLE READ` in SQL Server	`REPEATABLE READ` in Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Keine	Keine
`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	Keine	Keine
`SELECT * FROM employee;`	Leerlauf in Transaktion	Keine	Keine
`UPDATE employee SET name='A_TXN1' WHERE id=1;`	Leerlauf in Transaktion	Keine	Keine
Leerlauf in Transaktion	`SELECT * FROM employee WHERE id != 1;`	Keine	Keine
Leerlauf in Transaktion	`SELECT * FROM employee;`	Transaktion 2 ist blockiert, bis Transaktion 1 festgeschrieben wird.	Transaktion 2 wird normal fortgesetzt.
`COMMIT`	Leerlauf in Transaktion	Keine	Keine
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	Keine
Leerlauf in Transaktion	`SELECT * FROM employee;`	Sieht das Update von Transaktion 1	Sieht das Update von Transaktion 1

Die folgende Tabelle enthält Details zum Verhalten beim Blockieren von Schreib-/Schreibvorgängen, wenn gleichzeitige Transaktionen ausgeführt werden. Sie zeigt die beobachteten Ergebnisse bei der Verwendung der Isolationsstufe REPEATABLE READ in SQL Server im Vergleich zur REPEATABLE READ-Babelfish-Implementierung.

Transaktion 1	Transaktion 2	`REPEATABLE READ` in SQL Server	`REPEATABLE READ` in Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Keine	Keine
`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	Keine	Keine
`UPDATE employee SET name='A_TXN1' WHERE id=1;`	Leerlauf in Transaktion	Keine	Keine
Leerlauf in Transaktion	`UPDATE employee SET name='A_TXN2' WHERE id=1;`	Transaktion 2 wurde blockiert.	Transaktion 2 wurde blockiert.
`COMMIT`	Leerlauf in Transaktion	Das Festschreiben war erfolgreich und Transaktion 2 ist nicht mehr blockiert.	Das Festschreiben war erfolgreich und Transaktion 2 schlägt fehl mit dem Fehler: could not serialize access due to concurrent update.
Leerlauf in Transaktion	`COMMIT`	Festschreiben erfolgreich	Transaktion 2 wurde bereits abgebrochen.
Leerlauf in Transaktion	`SELECT * FROM employee;`	Die Zeile mit id=1 hat name='A_TX2'.	Die Zeile mit id=1 hat name='A_TX1'.

Die folgende Tabelle enthält Details zum Verhalten bei Phantomlesevorgängen, wenn gleichzeitige Transaktionen ausgeführt werden. Sie zeigt die beobachteten Ergebnisse bei der Verwendung der Isolationsstufe REPEATABLE READ in SQL Server im Vergleich zur REPEATABLE READ-Babelfish-Implementierung.

Transaktion 1	Transaktion 2	`REPEATABLE READ` in SQL Server	`REPEATABLE READ` in Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Keine	Keine
`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	Keine	Keine
`SELECT * FROM employee;`	Leerlauf in Transaktion	Keine	Keine
Leerlauf in Transaktion	`INSERT INTO employee VALUES (4, 'NewRowName', 20);`	Transaktion 2 wird ohne jegliche Blockierung fortgesetzt.	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	Keine
`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	Keine
`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 Details zur Ausführung gleichzeitiger Transaktionen und zu den unterschiedlichen Endergebnissen bei Verwendung der Isolationsstufe REPEATABLE READ in SQL Server im Vergleich zur REPEATABLE READ-Babelfish-Implementierung.

Transaktion 1	Transaktion 2	`REPEATABLE READ` in SQL Server	`REPEATABLE READ` in Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Keine	Keine
`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	Keine	Keine
`UPDATE employee SET age = 100 WHERE age IN (SELECT MIN(age) FROM employee);`	Leerlauf in Transaktion	Transaktion 1 aktualisiert die Zeile mit id 1.	Transaktion 1 aktualisiert die Zeile mit 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 id = 3 aktualisiert wird, da die Änderungen von 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 id = 1 wurde durch Transaktion 2 im vorherigen Schritt aktualisiert und ist hier sichtbar.	Die Zeile mit id = 3 wird durch Transaktion 2 aktualisiert.
`COMMIT`	Leerlauf in Transaktion	Transaktion 2 ist jetzt nicht mehr blockiert.	Festschreiben erfolgreich
Leerlauf in Transaktion	`COMMIT`	Keine	Keine
`SELECT * FROM employee;`	Leerlauf in Transaktion	Beide Transaktionen führen das Update für die Zeile mit id = 1 aus.	Verschiedene Zeilen werden durch Transaktion 1 und 2 aktualisiert.

Die Isolationsstufe `SERIALIZABLE` in Babelfish im Vergleich zur Isolationsstufe `SERIALIZABLE` in SQL Server

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

Transaktion 1	Transaktion 2	`SERIALIZABLE` in SQL Server	`SERIALIZABLE` in Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Keine	Keine
`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	Keine	Keine
`SELECT * FROM employee;`	Leerlauf in Transaktion	Keine	Keine
Leerlauf in Transaktion	`INSERT INTO employee VALUES (4, 'D', 35);`	Transaktion 2 ist blockiert, bis Transaktion 1 festgeschrieben wird.	Transaktion 2 wird ohne jegliche Blockierung fortgesetzt.
Leerlauf in Transaktion	`SELECT * FROM employee;`	Keine	Keine
`COMMIT`	Leerlauf in Transaktion	Transaktion 1 wird erfolgreich festgeschrieben. Transaktion 2 ist jetzt nicht mehr blockiert.	Transaktion 1 wird erfolgreich festgeschrieben.
Leerlauf in Transaktion	`COMMIT`	Keine	Keine
`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 Details zur Ausführung gleichzeitiger Transaktionen und zu den unterschiedlichen Endergebnissen bei Verwendung der Isolationsstufe SERIALIZABLE in SQL Server im Vergleich zur SERIALIZABLE-Babelfish-Implementierung.

Transaktion 1	Transaktion 2	`SERIALIZABLE` in SQL Server	`SERIALIZABLE` in Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Keine	Keine
`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	Keine	Keine
Leerlauf in Transaktion	`INSERT INTO employee VALUES (4, 'D', 40);`	Keine	Keine
`UPDATE employee SET age =99 WHERE id = 4;`	Leerlauf in Transaktion	Transaktion 1 ist blockiert, bis Transaktion 2 festgeschrieben wird.	Transaktion 1 wird ohne jegliche Blockierung fortgesetzt.
Leerlauf in Transaktion	`COMMIT`	Transaktion 2 wird erfolgreich festgeschrieben. Transaktion 1 ist jetzt nicht mehr blockiert.	Transaktion 2 wird erfolgreich festgeschrieben.
`COMMIT`	Leerlauf in Transaktion	Keine	Keine
`SELECT * FROM employee;`	Leerlauf in Transaktion	Die neu eingefügte Zeile ist mit age value = 99 sichtbar.	Die neu eingefügte Zeile ist mit age value = 40 sichtbar.

Die folgende Tabelle enthält Details zum Ausführen von INSERT für eine Tabelle mit eindeutiger Einschränkung. Sie zeigt die beobachteten Ergebnisse bei der Verwendung der Isolationsstufe SERIALIZABLE in SQL Server im Vergleich zur SERIALIZABLE-Babelfish-Implementierung.

Transaktion 1	Transaktion 2	`SERIALIZABLE` in SQL Server	`SERIALIZABLE` in Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Keine	Keine
`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	Keine	Keine
Leerlauf in Transaktion	`INSERT INTO employee VALUES (4, 'D', 40);`	Keine	Keine
`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 nicht mehr blockiert.	Transaktion 2 wird erfolgreich festgeschrieben. Transaktion 1 wurde abgebrochen mit dem Fehler: duplicate key value violates unique constraint.
`COMMIT`	Leerlauf in Transaktion	Transaktion 1 wird erfolgreich festgeschrieben.	Das Festschreiben von Transaktion 1 schlägt fehl mit: could not serialize access due to read or write dependencies among transactions.
`SELECT * FROM employee;`	Leerlauf in Transaktion	Die 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 aufgrund einer Serialisierungsanomalie fehl, wenn die Ausführung dieser Transaktionen nicht mit allen möglichen seriellen (einzeln ablaufenden) Ausführungen dieser Transaktionen übereinstimmt.

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

Transaktion 1	Transaktion 2	`SERIALIZABLE` in SQL Server	`SERIALIZABLE` in Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Keine	Keine
`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	Keine	Keine
`SELECT * FROM employee;`	Leerlauf in Transaktion	Keine	Keine
`UPDATE employee SET age=5 WHERE age=10;`	Leerlauf in Transaktion	Keine	Keine
Leerlauf in Transaktion	`SELECT * FROM employee;`	Transaktion 2 ist blockiert, bis Transaktion 1 festgeschrieben wird.	Transaktion 2 wird ohne jegliche Blockierung fortgesetzt.
Leerlauf in Transaktion	`UPDATE employee SET age=35 WHERE age=30;`	Keine	Keine
`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.	Das Festschreiben von Transaktion 2 schlägt mit einem Serialisierungsfehler fehl. Die gesamte Transaktion wurde zurückgesetzt. Transaktion 2 wird wiederholt.
`SELECT * FROM employee;`	Leerlauf in Transaktion	Änderungen aus beiden Transaktionen sind sichtbar.	Transaktion 2 wurde zurückgesetzt. Nur Änderungen an Transaktion 1 werden gesehen.

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

Transaktion 1	Transaktion 2	Isolationsstufen in SQL Server	Isolationsstufen in Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Keine	Keine
`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	Keine	Keine
`SELECT * FROM employee;`	Leerlauf in Transaktion	Keine	Keine
`UPDATE employee SET age=5 WHERE age=10;`	Leerlauf in Transaktion	Keine	Keine
Leerlauf in Transaktion	`SELECT * FROM employee;`	Transaktion 2 ist blockiert, bis Transaktion 1 festgeschrieben wird.	Transaktion 2 wird ohne jegliche Blockierung fortgesetzt.
Leerlauf in Transaktion	`UPDATE employee SET age=35 WHERE age=30;`	Keine	Keine
`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.

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Transaktionsisolationsstufen in Babelfish

Verwenden von Babelfish-Funktionen mit eingeschränkter Implementierung