Teilen über

Transaktionen in Fabric Data Warehouse

Gilt für:✅ SQL-Analyseendpunkt und Warehouse in Microsoft Fabric

Ähnlich wie in SQL Server ermöglichen Transaktionen die Steuerung des Commits oder Rollbacks von Lese- und Schreibabfragen.

Fabric Data Warehouse unterstützt ACID-kompatible Transaktionen. Jede Transaktion ist atomar, konsistent, isoliert und dauerhaft (ACID). Alle Vorgänge innerhalb einer einzelnen Transaktion werden atomar behandelt, entweder gelingen sie alle oder schlagen alle fehl. Wenn ein Befehl in der Transaktion fehlschlägt, wird die gesamte Transaktion zurückgesetzt.

Explizite Transaktionen

Sie können Daten ändern, die in Tabellen in einem Warehouse gespeichert sind, indem Sie explizite Transaktionen verwenden, um Änderungen zu gruppieren.

Beispielsweise können Sie Einfügungen in mehrere Tabellen committen oder in keine der Tabellen, wenn ein Fehler auftritt. Wenn Sie Details zu einer Bestellung ändern, die sich auf drei Tabellen auswirkt, können Sie diese Änderungen in einer einzelnen Transaktion gruppieren. Wenn diese Tabellen abgefragt werden, weisen sie somit entweder alle die Änderungen auf oder keine von ihnen. Transaktionen sind eine gängige Praxis, wenn Sie sicherstellen müssen, dass Ihre Daten über mehrere Tabellen hinweg konsistent sind.

Sie können standardmäßige T-SQL-Syntaxsteuerungsmechanismen (BEGIN TRANCOMMIT TRANund ROLLBACK TRAN) für explizite Transaktionen verwenden. Weitere Informationen finden Sie unter: - BEGIN TRANSACTION - COMMIT TRANSACTION - ROLLBACK TRANSACTION

Unterstützung von datenbankübergreifenden Abfragetransaktionen

Warehouse in Microsoft Fabric unterstützt Transaktionen, die sich über Lagerräume erstrecken, die sich innerhalb desselben Arbeitsbereichs befinden, einschließlich des Lesens vom SQL-Analyseendpunkt des Lakehouse. Ein Beispiel finden Sie unter Schreiben einer datenbankübergreifenden SQL-Abfrage.

Grundlegendes zum Sperren und Blockieren in Fabric Data Warehouse

Fabric Data Warehouse verwendet die Sperrung auf Tabellenebene, unabhängig davon, ob eine Abfrage eine Zeile oder viele berührt. Die folgende Tabelle enthält eine Liste der Sperren, die für verschiedene T-SQL-Vorgänge verwendet werden.

Anweisungstyp Vorgenommene Sperre
DML
SELECT Schema-Stability (Sch-S)
INSERT Intent Exclusive (IX)
DELETE Intent Exclusive (IX)
UPDATE Intent Exclusive (IX)
VERSCHMELZEN Intent Exclusive (IX)
KOPIEREN IN Intent Exklusiv (IX)
DDL
TABELLE ERSTELLEN Schema-Änderung (Sch-M)
ALTER TABLE Schema-Änderung (Sch-M)
DROP TABLE Schema-Änderung (Sch-M)
TABELLE ABSCHNEIDEN Schema-Änderung (Sch-M)
TABELLE ERSTELLEN ALS SELECT Schemaänderung (Sch-M)
ERSTELLE TABELLE ALS KLON VON Schemaänderung (Sch-M)

Sie können aktuelle aktive Sperren mit der dynamischen Verwaltungsansicht (DMV) sys.dm_tran_locks abfragen.

Weitere Informationen zu Sperren, Sperreskalation und Sperrkompatibilität finden Sie im Leitfaden zur Transaktionssperre und Zeilenversionsverwaltung.

Momentaufnahmeisolation

Fabric Data Warehouse erzwingt Snapshot-Isolation für alle Transaktionen. Die Momentaufnahme-Isolation ist eine zeilenbasierte Isolationsstufe, die Konsistenz auf Transaktionsebene für Daten bietet und Zeilenversionen verwendet, die in tempdb gespeichert sind, um auszuwählende Zeilen zu aktualisieren. Die Transaktion verwendet die Datenzeilenversionen, die vorhanden sind, wenn die Transaktion beginnt. Dadurch wird sichergestellt, dass jede Transaktion mit einer konsistenten Momentaufnahme der Daten arbeitet, wie sie zu Beginn der Transaktion vorhanden ist.

In der Snapshot-Isolation sehen die Abfragen in einer Transaktion dieselbe Version oder denselben Zustand der Datenbank, der zum Zeitpunkt des Beginns der Transaktion besteht. Bei der Schnappschussisolation blockieren Transaktionen, die Daten ändern, keine Transaktionen, die Daten lesen, und umgekehrt blockieren Transaktionen, die Daten lesen, keine Transaktionen, die Daten schreiben. Dieses optimistische, nicht blockierende Verhalten reduziert auch die Wahrscheinlichkeit von Deadlocks für komplexe Transaktionen erheblich.

Wenn Sie T-SQL verwenden, um Ihre Isolationsstufe zu ändern, wird die Änderung bei der Ausführung der Abfrage ignoriert und stattdessen die Schnappschussisolierung angewendet.

In der Momentaufnahmeisolation sind Schreib- oder Aktualisierungskonflikte möglich, weitere Informationen finden Sie unter Grundlegendes zu Schreibkonflikten in Fabric Data Warehouse.

Schemasperren

Schemensperren verhindern Konflikte bei DDL-Anweisungen, wie das Ändern des Schemas einer Tabelle, während in einer Transaktion Zeilen aktualisiert werden. Beachten Sie, dass DDL-Vorgänge, z. B. Schemaänderungen und Migrationen, durch aktive Lesearbeitslasten blockiert oder blockiert werden können.

  • Während DDL-Vorgängen (Data Definition Language) verwendet das Datenbankmodul Schemaänderungssperren (Sch-M). Während der Zeit, in der sie gehalten wird, verhindert die Sch-M Sperre den gesamten gleichzeitigen Zugriff auf die Tabelle, bis die Sperre aufgehoben wird.
  • Bei DML-Vorgängen (Data Manipulation Language) verwendet das Datenbankmodul Schemastabilitätssperren (Sch-S). Vorgänge, die Sch-M Sperren erhalten, werden durch die Sch-S Sperren blockiert. Andere Transaktionen werden weiterhin ausgeführt, während eine Abfrage kompiliert wird, aber DDL-Vorgänge werden blockiert, bis sie exklusiven Zugriff auf das Schema erhalten können.
  • DDL-Vorgänge erhalten für die Dauer der Transaktion auch eine exklusive (X) Sperre für Zeilen in Systemansichten wie sys.tables und sys.objects, die mit der Zieltabelle verbunden sind. Dadurch werden gleichzeitige SELECT Anweisungen auf sys.tables und sys.objects blockiert.

Bewährte Methoden zum Vermeiden der Blockierung

  • Vermeiden Sie lang andauernde Transaktionen oder planen Sie sie während Zeiträumen mit geringer oder keiner gleichzeitigen Aktivität.
  • Planen Sie DDL-Vorgänge nur während Wartungsfenstern, um die Blockierung zu minimieren.
  • Vermeiden Sie es, DDL-Anweisungen innerhalb expliziter Benutzertransaktionen zu platzieren (BEGIN TRAN). Lange ausgeführte Transaktionen, die Tabellen ändern, können zu Blockierungsproblemen bei anderen DML-Vorgängen und SELECT Abfragen führen, sowohl in Benutzertabellen als auch in Systemkatalogansichten wie sys.tables. Verwenden Sie sys.dm_tran_locks, um potenzielle Sperrkonflikte zu überwachen und zu beheben.
  • Überwachen Sie Sperren und Konflikte im Lager.
  • Fabric Data Warehouse unterstützt einige DDL-Anweisungen innerhalb von benutzerdefinierten Transaktionen, wird jedoch nicht in langfristigen Transaktionen empfohlen. Innerhalb von Transaktionen können DDL-Anweisungen gleichzeitige Transaktionen blockieren oder Schreibkonflikte verursachen.

Grundlegendes zu Schreibkonflikten in Fabric Data Warehouse

Schreibkonflikte können auftreten, wenn zwei Transaktionen versuchen, UPDATE, DELETE, MERGE oder TRUNCATE dieselbe Tabelle.

Schreibkonflikte oder Aktualisierungskonflikte sind auf Tabellenebene möglich, da Fabric Data Warehouse die Sperrung auf Tabellenebene verwendet. Wenn zwei Transaktionen versuchen, unterschiedliche Zeilen in derselben Tabelle zu ändern, können sie trotzdem in Konflikt geraten.

Schreibkonflikte treten hauptsächlich in zwei Szenarien auf:

  • Benutzerinduzierte Arbeitsauslastungskonflikte
    • Mehrere Benutzer oder Prozesse ändern gleichzeitig dieselbe Tabelle.
    • Kann in ETL-Pipelines, Batchaktualisierungen oder überlappenden Transaktionen auftreten.
  • Systeminduzierte Konflikte
    • Hintergrundsystemaufgaben wie automatische Datenkomprimierung schreiben Dateien mit schlechter Qualität um.
    • Diese können mit Benutzertransaktionen in Konflikt stehen, obwohl die Datenkomprimierung aktiv Schreibkonflikte dieses Typs verhindert.

Wenn ein Schreibkonflikt auftritt, werden möglicherweise Fehlermeldungen angezeigt, z. B.:

  • Fehler 24556: Die Snapshotisolationstransaktion wurde aufgrund eines Aktualisierungskonflikts abgebrochen. Die Verwendung der Snapshotisolation für den Zugriff auf die Tabelle '%.*ls' direkt oder indirekt in der Datenbank '%.*ls' kann zu Aktualisierungskonflikten führen, wenn Zeilen in dieser Tabelle durch eine andere gleichzeitige Transaktion gelöscht oder aktualisiert wurden. Wiederholen Sie die Transaktion.
  • Fehler 24706: Die Momentaufnahmeisolationstransaktion wurde aufgrund eines Aktualisierungskonflikts abgebrochen. Sie können die Snapshot-Isolation nicht verwenden, um direkt oder indirekt auf die Tabelle '%.*ls' in der Datenbank '%.*ls' zuzugreifen, um die Zeile zu aktualisieren, zu löschen oder einzufügen, die durch eine andere Transaktion geändert oder gelöscht wurde. Versuchen Sie die Transaktion erneut.

Wenn diese Fehlermeldungen auftreten, war mindestens eine Transaktion erfolgreich, und mindestens eine widersprüchliche Transaktion ist fehlgeschlagen. Wiederholen Sie die fehlgeschlagenen Transaktionen.

Hinweis

Selbst wenn MERGE Transaktionen nur zu Anfügeänderungen führen, erstellen sie dennoch einen Schreibkonflikt. Wenn eine Transaktion MERGE auf andere Zeilen als andere gleichzeitige DML-Transaktionen auswirkt, kann dieser Fehler auftreten, wenn MERGE nicht die erste Transaktion ist, die festgeschrieben wird: 'Snapshot-Isolationstransaktion aufgrund eines Aktualisierungskonflikts abgebrochen.'

Bewährte Methoden zum Vermeiden von Schreibkonflikten

So vermeiden Sie Schreibkonflikte:

  • Vermeiden Sie gleichzeitige UPDATE, DELETE, MERGE-Vorgänge in derselben Tabelle.
    • Achten Sie sorgfältig auf UPDATE, DELETE, MERGE-Operationen innerhalb von mehrstufigen Transaktionen.
  • Verwenden Sie "Wiederholungslogik" in allen Anwendungen und Abfragen.
    • Implementieren Sie die Wiederholungslogik in gespeicherten Prozeduren und ETL-Pipelines.
    • Fügen Sie einen Erneutversuch-Mechanismus mit Verzögerung in Pipelines oder Apps hinzu, um transiente Konflikte zu behandeln.
      • Verwenden Sie exponentielles Backoff, um Wiederholungsstürme zu vermeiden, die vorübergehende Netzwerkunterbrechungen verschlechtern. Weitere Informationen finden Sie unter "Wiederholungsmuster".
  • Schreibkonflikte mit dem Hintergrunddatenkomprimierungsdienst des Fabric Data Warehouse sind möglich, werden jedoch in der Regel durch die Verhinderung der Datenkomprimierung verhindert.

Tabellen- und Parquet-Dateisperrung

Konflikte aus mehreren gleichzeitigen Transaktionen, die Zeilen in einer Tabelle aktualisieren, werden am Ende der Transaktion ausgewertet. Die erste committete Transaktion wird erfolgreich abgeschlossen, und für die anderen Transaktionen wird ein Rollback ausgeführt und ein Fehler zurückgegeben. Diese Konflikte werden auf Tabellenebene und nicht auf der Ebene der einzelnen Parquet-Dateien ausgewertet.

INSERT-Anweisungen erstellen immer neue Parquet-Dateien, sodass es weniger Konflikte mit anderen Transaktionen gibt. Dies gilt nicht für DDL, da das Schema der Tabelle geändert werden kann.

Begrenzungen

  • Verteilte Transaktionen werden nicht unterstützt, z. B. BEGIN DISTRIBUTED TRANSACTION.
  • ALTER TABLE wird in einer expliziten Transaktion nicht unterstützt.
  • Speicherpunkte werden nicht unterstützt.
  • Benannte Transaktionen werden nicht unterstützt.
  • Markierte Transaktionen werden nicht unterstützt.
  • Derzeit ist die T-SQL-Funktionalität im Warehouse eingeschränkt. Eine Liste der T-SQL-Befehle, die derzeit nicht verfügbar sind, finden Sie unter T-SQL-Oberflächenbereich in Fabric Data Warehouse .
  • Wenn bei einer Transaktion Daten in eine leere Tabelle eingefügt werden und vor dem Rollback eine SELECT-Anweisung ausgegeben wird, können die automatisch generierten Statistiken weiterhin die nicht committeten Daten widerspiegeln, sodass es zu ungenauen Statistiken kommt. Ungenaue Statistiken können zu nicht optimierten Abfrageplänen und Ausführungszeiten führen. Wenn Sie ein Rollback für eine Transaktion mit SELECT-Anweisungen nach einem großen INSERT-Vorgang durchführen, aktualisieren Sie die Statistiken für die in der SELECT-Anweisung genannten Spalten.

Zugehöriger Inhalt

  • Last updated on