Containerübergreifende Transaktionen

Containerübergreifende Transaktionen sind implizite oder explizite Benutzertransaktionen, die Aufrufe von nativ kompilierten gespeicherten Prozeduren oder Vorgängen für speicheroptimierte Tabellen enthalten.

In SQL Server initiieren Aufrufe gespeicherter Prozeduren keine Transaktion. Ausführungen systemeigener kompilierter Prozeduren im Autocommit-Modus (nicht im Kontext einer Benutzertransaktion) gelten nicht als containerübergreifende Transaktionen.

Jede interpretierte Abfrage, die auf speicheroptimierte Tabellen verweist, wird als Teil einer containerübergreifenden Transaktion betrachtet, unabhängig davon, ob sie von einer expliziten oder impliziten Transaktion oder im Automatischen Commit-Modus ausgeführt wird.

Isolation einzelner Vorgänge

Jede SQL Server-Transaktion verfügt über eine Isolationsstufe. Die Standardisolationsstufe ist Read Committed. Um eine andere Isolationsstufe zu verwenden, können Sie die Isolationsstufe mit SET TRANSACTION ISOLATION LEVEL (Transact-SQL) festlegen.

Es ist häufig erforderlich, Vorgänge für speicheroptimierte Tabellen auf einer anderen Isolationsebene auszuführen als Vorgänge auf datenträgerbasierten Tabellen. In einer Transaktion ist es möglich, eine andere Isolationsstufe für eine Sammlung von Anweisungen oder für einen einzelnen Lesevorgang festzulegen.

Angeben der Isolationsebene einzelner Vorgänge

Um eine andere Isolationsstufe für eine Reihe von Anweisungen in einer Transaktion festzulegen, können Sie verwenden SET TRANSACTION ISOLATION LEVEL. Im folgenden Beispiel einer Transaktion wird die serialisierbare Isolationsstufe als Standard verwendet. Die Einfüge- und Auswahlvorgänge für t3, t2 und t1 werden unter wiederholbarer Leseisolation ausgeführt.

set transaction isolation level serializable  
go  
  
begin transaction  
 ......  
  set transaction isolation level repeatable read  
  
  insert t3 select * from t1 join t2 on t1.id=t2.id  
  
  set transaction isolation level serializable  
 ......  
commit  

Um eine Isolationsstufe für einzelne Lesevorgänge festzulegen, die sich vom Transaktionsstandard unterscheiden, können Sie einen Tabellenhinweis (z. B. serialisierbar) verwenden. Jede Auswahl entspricht einem Lesevorgang und jeder Aktualisierung und jeder Löschvorgang einem Lesevorgang, da die Zeile immer gelesen werden muss, bevor sie aktualisiert oder gelöscht werden kann. Einfügevorgänge verfügen nicht über eine Isolationsstufe, da Schreibvorgänge immer in SQL Server isoliert sind. Im folgenden Beispiel ist die Standardisolationsstufe für die Transaktion "Read Committed". Jedoch wird auf Tabelle t1 unter serialisierbarer Isolierung und auf t2 unter Snapshot-Isolation zugegriffen.

set transaction isolation level read committed  
go  
  
begin transaction  
 ......  
  
  insert t3 select * from t1 (serializable) join t2 (snapshot) on t1.id=t2.id  
  
  ......  
commit  

Isolationsemantik für einzelne Vorgänge

Eine serialisierbare Transaktion T wird vollständig isoliert ausgeführt. Es ist, als ob jede andere Transaktion entweder abgeschlossen wurde, bevor T gestartet hat, oder gestartet wurde, nachdem T abgeschlossen hat. Es wird komplexer, wenn verschiedene Vorgänge in einer Transaktion unterschiedliche Isolationsstufen aufweisen.

Die allgemeine Semantik der Transaktionsisolationsstufen in SQL Server zusammen mit den Auswirkungen auf die Sperrung wird in SET TRANSACTION ISOLATION LEVEL (Transact-SQL) erläutert.

Bei containerübergreifenden Transaktionen, bei denen unterschiedliche Vorgänge unterschiedliche Isolationsstufen aufweisen, müssen Sie die Semantik der Isolation einzelner Lesevorgänge verstehen. Schreibvorgänge sind immer isoliert. Schreibvorgänge in verschiedenen Transaktionen können sich nicht gegenseitig beeinflussen.

Ein Datenlesevorgang gibt eine Reihe von Zeilen zurück, die eine Filterbedingung erfüllen.

Lesevorgänge werden als Teil einer Transaktion T ausgeführt. Isolationsstufen für Lesevorgänge können in Bezug auf Folgendes verstanden werden:

Status des Commits
Der Commit-Status bezieht sich darauf, ob garantiert ist, dass die gelesenen Daten wirklich festgeschrieben wurden.

(Transaktional) Konsistenz
Transaktionskonsistenz für eine Gruppe von Lesevorgängen bezieht sich darauf, ob die gelesenen Zeilenversionen garantiert Aktualisierungen aus genau demselben Satz von Transaktionen enthalten.

Stabilität garantiert, dass das System Transaktion T über die Stabilität der gelesenen Daten informiert.
Stabilität bezieht sich darauf, ob die Lesevorgänge der Transaktion wiederholbar sind. Das heißt, wenn die Lesevorgänge wiederholt würden, würden sie dieselben Zeilen- und Zeilenversionen zurückgeben?

Bestimmte Garantien beziehen sich auf die logische Endzeit der Transaktion. Im Allgemeinen ist die logische Endzeit der Zeitpunkt, zu dem die Transaktion an die Datenbank gebunden ist. Wenn durch die Transaktion auf speicheroptimierte Tabellen zugegriffen wird, ist die logische Endzeit technisch der Anfang der Validierungsphase. (Weitere Informationen finden Sie in der Diskussion zur Transaktionslebensdauer in Transaktionen in Memory-Optimized Tabellen.

Unabhängig von der Isolationsstufe sieht eine Transaktion (T) immer ihre eigenen Updates.

UNKOMMISSIONIERT LESEN
Die gelesenen Daten dürfen weder zugesichert noch konsistent oder stabil sein. Sie enthält jedoch frühere Schreibvorgänge, die von T ausgeführt werden.

Gelesen mit Bestätigung
Die gelesenen Daten werden eingefügt.

SCHNAPPSCHUSS
Alle Lesevorgänge, die von T unter Momentaufnahmeisolation ausgeführt werden, weisen die gleiche logische Lesezeit auf, was der Anfang der Transaktion ist. Die gelesenen Daten sind garantiert festgeschrieben und konsistent zum Zeitpunkt des logischen Lesezeitpunkts. Das Wiederholen eines Lesevorgangs ab der ursprünglichen Lesezeit ist garantiert, dass dasselbe Ergebnis zurückgegeben wird.

WIEDERHOLBARES LESEN
Die eingelesenen Daten sind garantiert festgeschrieben und bis zum logischen Endzeitpunkt der Transaktion stabil.

SERIALISIERBAR
Alle Garantien von REPEATABLE READ plus Phantomvermeidung und Transaktionskonsistenz in Bezug auf alle serialisierbaren Lesevorgänge von T. Phantom-Vermeidung bedeutet, dass der Scanvorgang nur zusätzliche Zeilen zurückgeben kann, die von T geschrieben wurden, aber keine Zeilen, die von anderen Transaktionen geschrieben wurden.

Betrachten Sie die folgende Transaktion:

set transaction isolation level read committed  
go  
  
begin transaction  
  -- remove all rows from t3; the related read operation is performed under read committed   
  -- isolation, as this is the default for the transaction  
  delete from t3  
  
  -- copy the contents from t1 to t3; the read on t1 is performed under the serializable   
  -- isolation level  
  insert t3 select * from t1 (serializable)  
  
  -- compare t3 and t1; note: the result set may not be empty, as rows may have been added   
  -- by other transaction before this select, due to the read committed isolation level  
  select * from t3 except t1  
  
  -- compare t1 and t3; note: the result set is empty, as no rows have been added to t1   
  -- since its contents were copied to t1, due to the serializable isolation level  
  select * from t1 except t3  
commit  

Diese Transaktion löscht alle Zeilen aus t3 unter der Isolation 'Read Committed', kopiert alle Zeilen von t1 nach t3 unter serialisierbarer Isolation und vergleicht dann t1 und t3. Einige Zeilen [nicht in t1] wurden möglicherweise zu t3 hinzugefügt, da die Tabelle geleert wurde. Es wurden keine Zeilen zu t1 hinzugefügt, da die Kopie serialisierbar war.

Obwohl das Lesen von t1 am Ende der Transaktion syntaktisch gelesen wird, ist es effektiv serialisierbar, da derselbe Lesevorgang früher in der Transaktion unter serialisierbarer Isolation durchgeführt wurde: Serialisierungssicherheit garantiert, dass, wenn der Lesevorgang zu einem späteren Zeitpunkt in der Transaktion ausgeführt wird, dieselben Zeilen zurückgegeben werden.

Containerübergreifende Transaktionen und Isolationsstufen

Eine containerübergreifende Transaktion kann als zwei Seiten betrachtet werden: eine datenträgerbasierte Seite (für Vorgänge auf datenträgerbasierten Tabellen) und eine speicheroptimierte Seite (für Vorgänge in speicheroptimierten Tabellen). Diese beiden Seiten können unterschiedliche Isolationsstufen aufweisen. Tatsächlich können einzelne Lesevorgänge auf jeder Seite unterschiedliche Isolationsstufen aufweisen.

Die datenträgerbasierte Seite einer bestimmten Transaktion T erreicht eine bestimmte Isolationsstufe X, wenn eine der folgenden Bedingungen erfüllt ist:

• Es beginnt in X. Das heißt, der Sitzungsstandard war X, entweder weil Sie ausgeführt SET TRANSACTION ISOLATION LEVELhaben, oder es ist die SQL Server-Standardeinstellung.

• Während der Transaktion wird die Standardisolationsstufe mithilfe von X mit SET TRANSACTION ISOLATION LEVEL geändert.

• Ein Lesevorgang für eine datenträgerbasierte Tabelle wird unter Isolationsebene X mithilfe der Syntax WITH (X)ausgeführt.

Die speicheroptimierte Seite von T erreicht eine Isolationsstufe Y, wenn während der Ausführung von T alle Lesevorgänge in einer speicheroptimierten Tabelle oder eine systemeigene gespeicherte Prozedur unter Isolationsstufe Y ausgeführt werden.

Betrachten Sie die folgende Transaktion als Beispiel. Hier sind t1 und t2 datenträgerbasierte Tabellen und t3 und t4 speicheroptimierte Tabellen.

Die datenträgerbasierte Komponente der Transaktion erreicht den Isolationsgrad READ COMMITTED, da sie auf dieser Ebene beginnt. Die datenträgerbasierte Seite erreicht auch wiederholbares Lesen, da der erste Lesevorgang unter dieser Isolationsebene ausgeführt wird. Das Löschen am Ende der Transaktion wird unter der Read-Committed-Isolationsstufe ausgeführt und führt daher keine neue Isolationsstufe ein.

Die speicheroptimierte Seite der Transaktion kann eine von zwei Ebenen erreichen: Wenn Bedingung1 wahr ist, wird der serialisierbare Grad erreicht; ist Bedingung1 falsch, erreicht die speicheroptimierte Seite nur die Schnappschussisolation.

set transaction isolation level read committed  
go  
  
begin transaction  
  select * from t1 (repeatableread)  
  
  if condition1 begin  
    insert t3 select * from t4 (serializable)  
  end  
  else begin  
    insert t3 select * from t4 (snapshot)  
  end  
  
  delete from t1  
commit  

Unterstützte Isolationsebenen für containerübergreifende Transaktionen

Es gibt Einschränkungen für die Isolationsebenen, die bei Vorgängen mit speicheroptimierten Tabellen in containerübergreifenden Transaktionen verwendet werden.

Speicheroptimierte Tabellen unterstützen die Isolationsstufen SNAPSHOT, REPEATABLE READ und SERIALIZABLE. Bei Autocommit-Transaktionen unterstützen speicheroptimierte Tabellen die Isolationsstufe „READ COMMITTED“.

Folgende Szenarios werden unterstützt:

• READ UNCOMMITTED, READ COMMITTED, and READ_COMMITTED_SNAPSHOT-Cross-Container-Transaktionen können speicheroptimierte Tabellen unter SNAPSHOT-, REPEATABLE READ- und SERIALIZABLE-Isolation aufrufen. Die READ COMMITTED-Garantie gilt für die Transaktion; alle Zeilen, die von der Transaktion gelesen werden, wurden in die Datenbank übernommen.

• WIEDERHOLBARE LESE- und SERIALISABLE-Transaktionen können unter SNAPSHOT-Isolation auf speicheroptimierte Tabellen zugreifen.

Schreibgeschützte containerübergreifende Transaktionen

Die meisten schreibgeschützten Transaktionen in SQL Server werden zur Commitzeit zurückgesetzt. Da keine Änderungen an der Datenbank vorgenommen werden, gibt das System einfach die von der Transaktion verwendeten Ressourcen frei. Bei schreibgeschützten datenträgerbasierten Transaktionen werden derzeit alle Sperren der Transaktion freigegeben. Bei schreibgeschützten speicheroptimierten Transaktionen, die eine einzige systemeigene kompilierte Prozedurausführung umfassen, wird keine Überprüfung ausgeführt.

Containerübergreifende, schreibgeschützte Transaktionen im Autocommit-Modus werden am Ende der Transaktion einfach rückgängig gemacht. Es wird keine Überprüfung durchgeführt.

Explizite oder implizite containerübergreifende Transaktionen führen zur Commitzeit eine Überprüfung durch, wenn die Transaktion auf speicheroptimierte Tabellen unter REPEATABLE READ- oder SERIALIZABLE-Isolation zugreift. Ausführliche Informationen zur Überprüfung finden Sie im Abschnitt "Konflikterkennungs-, Validierungs- und Commit-Abhängigkeitsüberprüfungen in Transaktionen in Memory-Optimized Tabellen".

Siehe auch

Grundlegendes zu Transaktionen in Memory-Optimized Tabellen
Richtlinien zu den Isolationsstufen von Transaktionen mit Memory-Optimized-Tabellen
Richtlinien für die Wiederholungslogik für Transaktionen in Memory-Optimized Tabellen