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.
Transaktionsisolationsstufen in Babelfish
Babelfish unterstützt die Transaktionsisolationsstufen READ UNCOMMITTED, READ COMMITTED und SNAPSHOT. Ab der Babelfish-Version 3.4 werden die zusätzlichen Isolationsstufen REPEATABLE READ und SERIALIZABLE unterstützt. Alle Isolationsstufen in Babelfish werden mit dem Verhalten der entsprechenden Isolationsstufen in PostgreSQL unterstützt. SQL Server und Babelfish verwenden unterschiedliche grundlegende Mechanismen zur Implementierung von Isolationsstufen für Transaktionen (Blockierung für gleichzeitigen Zugriff, Sperren aufgrund von Transaktionen, Fehlerbehandlung usw.). Und es gibt einige subtile Unterschiede darin, wie sich der gleichzeitige Zugriff für unterschiedliche Workloads auswirken kann. Weitere Informationen zu diesem PostgreSQL-Verhalten finden Sie unter Transaktionsisolation
Themen
Übersicht über die Transaktionsisolationsstufen
Die ursprünglichen SQL-Server-Transaktionsisolationsstufen basieren auf pessimistischen Sperren, bei denen nur eine Kopie der Daten vorhanden ist und Abfragen Ressourcen wie Zeilen sperren müssen, bevor auf sie zugegriffen werden kann. Später wurde eine Variante der Isolationsstufe READ COMMITTED eingeführt. Dies ermöglicht die Verwendung von Zeilenversionen, um eine bessere Parallelität zwischen Lesern und Schreibern zu gewährleisten, indem der Zugriff nicht blockiert wird. Darüber hinaus ist eine neue Isolationsstufe namens SNAPSHOT verfügbar. Außerdem werden Zeilenversionen verwendet, um eine bessere Parallelität als die Isolationsstufe REPEATABLE READ zu gewährleisten, indem gemeinsame Sperren für gelesene Daten vermieden werden, die bis zum Ende der Transaktion aufbewahrt werden.
Im Gegensatz zu SQL Server basieren alle Transaktionsisolationsstufen in Babelfish auf optimistischen Sperren (MVCC). Jede Transaktion sieht einen Snapshot der Daten entweder zu Beginn der Anweisung (READ COMMITTED) oder zu Beginn der Transaktion (REPEATABLE READ, SERIALIZABLE), unabhängig vom aktuellen Status der zugrunde liegenden Daten. Daher kann sich das Ausführungsverhalten gleichzeitiger Transaktionen in Babelfish von dem in SQL Server unterscheiden.
Stellen Sie sich zum Beispiel eine Transaktion mit der Isolationsstufe SERIALIZABLE vor, die zunächst in SQL Server blockiert wird, aber später erfolgreich ist. Sie kann in Babelfish aufgrund eines Serialisierungskonflikts mit einer gleichzeitigen Transaktion, die dieselben Zeilen liest oder aktualisiert, fehlschlagen. Es kann auch Fälle geben, in denen die Ausführung mehrerer gleichzeitiger Transaktionen in Babelfish zu einem anderen Endergebnis führt als in SQL Server. Anwendungen, die Isolationsstufen verwenden, sollten gründlich auf Parallelitätsszenarien getestet werden.
| Isolationsstufen in SQL Server | Babelfish-Isolationsstufe | PostgreSQL-Isolationsstufe | Kommentare |
|---|---|---|---|
|
|
|
|
|
|
|
|
|
SQL Server |
|
|
|
|
Beide basieren auf Snapshots (MVCC), sind aber nicht exakt identisch. |
|
|
|
|
Genau dasselbe |
|
|
|
|
SQL Server |
|
|
|
|
SQL Server |
Anmerkung
Die Tabellenhinweise werden derzeit nicht unterstützt und ihr Verhalten wird mithilfe der vordefinierten Notfalloption escape_hatch_table_hints von Babelfish gesteuert.
Einrichten der Transaktionsisolationsstufen
Verwenden Sie den folgenden Befehl, um eine Transaktionsisolationsstufe festzulegen:
SET TRANSACTION ISOLATION LEVEL { READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SNAPSHOT | SERIALIZABLE }
Aktivieren oder Deaktivieren von Transaktionsisolationsstufen
Die Transaktionsisolationsstufen REPEATABLE READ und SERIALIZABLE sind in Babelfish standardmäßig deaktiviert und Sie müssen sie explizit aktivieren, indem Sie die Notfalloption babelfishpg_tsql.isolation_level_serializable oder babelfishpg_tsql.isolation_level_repeatable_read mithilfe von sp_babelfish_configure auf pg_isolation setzen. Weitere Informationen finden Sie unter Verwalten der Babelfish-Fehlerbehandlung mit Escape-Schraffuren.
Im Folgenden finden Sie Beispiele, wie Sie die Verwendung von REPEATABLE READ und SERIALIZABLE in der aktuellen Sitzung aktivieren oder deaktivieren können, indem Sie die entsprechenden Notfalloptionen setzen. Fügen Sie optional den Parameter server hinzu, um die Notfalloption für die aktuelle Sitzung sowie für alle nachfolgenden neuen Sitzungen festzulegen.
Zum Aktivieren der Verwendung von SET TRANSACTION ISOLATION LEVEL REPEATABLE READ nur in der aktuellen Sitzung
EXECUTE sp_babelfish_configure 'isolation_level_repeatable_read', 'pg_isolation'
Zum Aktivieren der Verwendung von SET TRANSACTION ISOLATION LEVEL REPEATABLE READ in der aktuellen Sitzung und allen nachfolgenden neuen Sitzungen
EXECUTE sp_babelfish_configure 'isolation_level_repeatable_read', 'pg_isolation', 'server'
Zum Deaktivieren der Verwendung von SET TRANSACTION ISOLATION LEVEL REPEATABLE READ in der aktuellen Sitzung und nachfolgenden neuen Sitzungen
EXECUTE sp_babelfish_configure 'isolation_level_repeatable_read', 'off', 'server'
Zum Aktivieren der Verwendung von SET TRANSACTION ISOLATION LEVEL SERIALIZABLE nur in der aktuellen Sitzung
EXECUTE sp_babelfish_configure 'isolation_level_serializable', 'pg_isolation'
Zum Aktivieren der Verwendung von SET TRANSACTION ISOLATION LEVEL SERIALIZABLE in der aktuellen Sitzung und allen nachfolgenden neuen Sitzungen
EXECUTE sp_babelfish_configure 'isolation_level_serializable', 'pg_isolation', 'server'
Zum Deaktivieren der Verwendung von SET TRANSACTION ISOLATION LEVEL SERIALIZABLE in der aktuellen Sitzung und nachfolgenden neuen Sitzungen
EXECUTE sp_babelfish_configure 'isolation_level_serializable', 'off', 'server'
