Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Vergleich der Isolationsstufen in Babelfish und SQL Server
<a name="babelfish-transaction.examples"></a>

 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);
```

**Topics**
+ [Die Isolationsstufe `READ UNCOMMITTED` in Babelfish im Vergleich zur Isolationsstufe `READ UNCOMMITTED` in SQL Server](#babelfish-transaction.examples.unc)
+ [Die Isolationsstufe `READ COMMITTED` in Babelfish im Vergleich zur Isolationsstufe `READ COMMITTED` in SQL Server](#babelfish-transaction.examples.com)
+ [Die Isolationsstufe `READ COMMITTED` in Babelfish im Vergleich zur Isolationsstufe `READ COMMITTED SNAPSHOT` in SQL Server](#babelfish-transaction.examples.snapshot)
+ [Die Isolationsstufe `REPEATABLE READ` in Babelfish im Vergleich zur Isolationsstufe `REPEATABLE READ` in SQL Server](#babelfish-transaction.examples.read)
+ [Die Isolationsstufe `SERIALIZABLE` in Babelfish im Vergleich zur Isolationsstufe `SERIALIZABLE` in SQL Server](#babelfish-transaction.examples.serialize)

## Die Isolationsstufe `READ UNCOMMITTED` in Babelfish im Vergleich zur Isolationsstufe `READ UNCOMMITTED` in SQL Server
<a name="babelfish-transaction.examples.unc"></a>

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
<a name="babelfish-transaction.examples.com"></a>

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
<a name="babelfish-transaction.examples.snapshot"></a>

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
<a name="babelfish-transaction.examples.read"></a>

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
<a name="babelfish-transaction.examples.serialize"></a>

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. |