Share via

Transacties in Fabric Data Warehouse

Van toepassing op:✅ SQL Analytics-eindpunt en -magazijn in Microsoft Fabric

Net als bij hun gedrag in SQL Server kunt u met transacties het doorvoeren of terugdraaien van lees- en schrijfquery's beheren.

Fabric Data Warehouse ondersteunt ACID-compatibele transacties. Elke transactie is atomisch, consistent, geïsoleerd en duurzaam (ACID). Alle bewerkingen binnen één transactie worden atomisch behandeld, allemaal geslaagd of allemaal mislukt. Als een opdracht binnen de transactie mislukt, wordt de hele transactie teruggedraaid.

Expliciete transacties

U kunt gegevens wijzigen die zijn opgeslagen in tabellen in een magazijn met behulp van expliciete transacties om wijzigingen te groeperen.

U kunt bijvoorbeeld invoegen in veelvoudentabellen doorvoeren, of geen van de tabellen als er een fout optreedt. Als u details wijzigt over een inkooporder die van invloed is op drie tabellen, kunt u deze wijzigingen groeperen in één transactie. Dat betekent dat wanneer er query's worden uitgevoerd op deze tabellen, ze allemaal de wijzigingen hebben of geen van deze tabellen. Transacties zijn gebruikelijk wanneer u ervoor moet zorgen dat uw gegevens consistent zijn in meerdere tabellen.

U kunt standaardmechanismen voor T-SQL (BEGIN TRANen COMMIT TRANROLLBACK TRAN) voor het beheren van syntaxis gebruiken voor expliciete transacties. Zie voor meer informatie: - TRANSACTIE STARTEN - TRANSACTIE BEVESTIGEN - TRANSACTIE TERUGDRAAIEN

Ondersteuning voor transactie tussen databases

Warehouse in Microsoft Fabric ondersteunt transacties die betrekking hebben op magazijnen die zich in dezelfde werkruimte bevinden, inclusief het lezen van het SQL-analyse-eindpunt van Lakehouse. Zie Een SQL-query voor meerdere databases schrijven voor een voorbeeld.

Inzicht in vergrendeling en blokkering in Fabric Data Warehouse

Fabric Data Warehouse maakt gebruik van vergrendeling op tabelniveau, ongeacht of een query één rij of veel raakt. De volgende tabel bevat een lijst met de vergrendelingen die worden gebruikt voor verschillende T-SQL-bewerkingen.

Instructietype Vergrendeling genomen
DML
SELECT Schema-Stability (Sch-S)
INSERT Intentie exclusief (IX)
DELETE Intentie exclusief (IX)
UPDATE Intent Exclusief (IX)
MERGE Intent-exclusief (IX)
KOPIËREN NAAR Intentie exclusief (IX)
DDL
TABEL MAKEN Schema-wijziging (Sch-M)
ALTER TABLE (een SQL-opdracht om een tabel te wijzigen) Schema-Modification (Sch-M)
DROP TABLE Schema-wijziging (Sch-M)
TRUNCATE TABLE Schema-wijziging (Sch-M)
TABEL AANMAKEN ALS SELECTEREN Schema-wijziging (Sch-M)
TABEL AANMAKEN ALS EEN KLOON VAN Schema-Modificatie (Sch-M)

U kunt momenteel queryvergrendelingen uitvoeren met de dynamische beheerweergave (DMV) sys.dm_tran_locks.

Zie de handleiding voor transactievergrendelingen en rijversiebeheer voor meer informatie over vergrendelingen, escalatie van vergrendelingen en vergrendelingscompatibiliteit.

Isolatie van momentopnamen

Fabric Data Warehouse dwingt isolatie van momentopnamen af voor alle transacties. Snapshotisolatie is een rijgebaseerd isolatieniveau dat consistentie op transactieniveau biedt voor gegevens, en gebruikt rijversies die in tempdb zijn opgeslagen om te bepalen welke rijen moeten worden bijgewerkt. De transactie maakt gebruik van de gegevensrijversies die bestaan wanneer de transactie begint. Dit zorgt ervoor dat elke transactie werkt op een consistente momentopname van de gegevens zoals deze aan het begin van de transactie bestonden.

Bij isolatie van momentopnamen zien query's in de transactie dezelfde versie of momentopname, op basis van de status van de database wanneer de transactie begint. Bij snapshot-isolatie blokkeren transacties die gegevens wijzigen geen transacties die gegevens lezen, en transacties die gegevens lezen blokkeren geen transacties die gegevens schrijven. Dit optimistische, niet-blokkerende gedrag vermindert ook de kans op impasses voor complexe transacties aanzienlijk.

Als u T-SQL gebruikt om uw isolatieniveau te wijzigen, wordt de wijziging genegeerd tijdens de uitvoering van query's en wordt de isolatie van momentopnamen toegepast.

In snapshotisolatie zijn schrijf-schrijf of updateconflicten mogelijk, voor meer informatie zie Begrijp schrijf-schrijf-conflicten in Fabric Data Warehouse.

Schemavergrendelingen

Schemavergrendelingen voorkomen conflicten in DDL-instructies, zoals het schema van een tabel dat wordt gewijzigd terwijl rijen in een transactie worden bijgewerkt. Houd er rekening mee dat DDL-bewerkingen, zoals schemawijzigingen en migraties, kunnen blokkeren of worden geblokkeerd door actieve leesbelastingen.

  • Tijdens DDL-bewerkingen (Data Definition Language) gebruikt de database-engine schemawijzigingsvergrendelingenSch-M. Tijdens de tijd dat deze wordt vastgehouden, voorkomt de Sch-M vergrendeling alle gelijktijdige toegang tot de tabel totdat de vergrendeling wordt vrijgegeven.
  • Tijdens DML-bewerkingen (Data Manipulat Language) gebruikt de database-engine schemastabiliteitsvergrendelingenSch-S. Bewerkingen die Sch-M vergrendelingen verkrijgen, worden geblokkeerd door Sch-S vergrendelingen. Andere transacties blijven worden uitgevoerd terwijl een query wordt gecompileerd, maar DDL-bewerkingen worden geblokkeerd totdat ze exclusieve toegang tot het schema krijgen.
  • DDL-bewerkingen verkrijgen ook een exclusieve (X) vergrendeling op rijen in systeemweergaven zoals sys.tables en sys.objects gekoppeld aan de doeltabel, voor de duur van de transactie. Hiermee blokkeert u gelijktijdige SELECT instructies voor sys.tables en sys.objects.

Aanbevolen procedures om blokkeren te voorkomen

  • Vermijd langlopende transacties of planning tijdens perioden met een lage of geen gelijktijdige activiteit.
  • Plan alleen DDL-bewerkingen tijdens onderhoudsvensters om blokkeren te minimaliseren.
  • Vermijd het plaatsen van DDL-instructies binnen expliciete gebruikerstransacties (BEGIN TRAN). Langlopende transacties die tabellen wijzigen, kunnen blokkerende problemen veroorzaken voor andere DML-bewerkingen en SELECT query's, zowel op gebruikerstabellen als in systeemcatalogusweergaven, zoals sys.tables. Als u potentiële vergrendelingsconflicten wilt bewaken en oplossen, gebruikt u sys.dm_tran_locks.
  • Controleer vergrendelingen en conflicten in het magazijn.
  • Fabric Data Warehouse ondersteunt enkele DDL-instructies binnen door de gebruiker gedefinieerde transacties, maar deze worden niet aanbevolen in langlopende transacties. Binnen transacties kunnen DDL-instructies gelijktijdige transacties blokkeren of schrijf-schrijfconflicten veroorzaken.

Begrijp schrijf-schrijfconflicten in Fabric Data Warehouse

Schrijf-schrijfconflicten kunnen optreden wanneer twee transacties proberen UPDATE, DELETE, MERGE, of TRUNCATE dezelfde tabel te gebruiken.

Schrijf-schrijfconflicten of updateconflicten zijn mogelijk op tabelniveau, omdat Fabric Data Warehouse vergrendeling op tabelniveau gebruikt. Als twee transacties proberen om verschillende rijen in dezelfde tabel te wijzigen, kunnen ze nog steeds conflicteren.

Schrijf-schrijfconflicten ontstaan meestal uit twee situaties.

  • Door de gebruiker geïnduceerde workloadconflicten
    • Meerdere gebruikers of processen wijzigen tegelijkertijd dezelfde tabel.
    • Kan optreden in ETL-pijplijnen, batchupdates of bij overlappende transacties.
  • Door het systeem geïnduceerde conflicten
    • Achtergrondsysteemtaken zoals het automatisch comprimeren van gegevens herschrijven bestanden met een slechte kwaliteit.
    • Deze kunnen conflicteren met gebruikerstransacties, maar gegevenscompactie-preemptie voorkomt actief dit type schrijfconflict.

Als er een schrijf-schrijfconflict optreedt, ziet u mogelijk foutberichten zoals:

  • Fout 24556: Transactie voor isolatie van momentopnamen is afgebroken vanwege een updateconflict. Het gebruik van momentopname-isolatie voor directe of indirecte toegang tot tabel '%.*ls' in database '%.*ls' kan updateconflicten veroorzaken, als rijen in die tabel zijn verwijderd of gewijzigd door een andere gelijktijdige transactie. Voer de transactie opnieuw uit.
  • Fout 24706: Isolatietransactie voor momentopname is afgebroken vanwege een updateconflict. U kunt snapshotisolatie niet gebruiken om direct of indirect toegang te krijgen tot tabel '%.*ls' in database '%.*ls' om de rij bij te werken, te verwijderen of in te voegen die is gewijzigd of verwijderd door een andere transactie. Probeer de transactie opnieuw.

Als u deze foutberichten tegenkomt, zijn een of meer transacties geslaagd en is een of meer conflicterende transacties mislukt. Voer de transacties die zijn mislukt opnieuw uit.

Opmerking

Zelfs wanneer MERGE transacties alleen leiden tot toevoegende wijzigingen, veroorzaken ze nog steeds een schrijversconflict. Wanneer MERGE transactie van invloed is op verschillende rijen dan andere gelijktijdige DML-transacties, kan deze fout optreden als MERGE dit niet de eerste transactie is die moet worden doorgevoerd: 'Transactie voor momentopname-isolatie is afgebroken vanwege updateconflict'.

Best practices om schrijfconflicten te voorkomen

Conflicten bij gelijktijdig schrijven voorkomen:

  • Vermijd gelijktijdige UPDATEbewerkingen DELETEMERGE in dezelfde tabel.
    • Let zorgvuldig op UPDATE, DELETEMERGE bewerkingen binnen transacties met meerdere stappen.
  • Gebruik logica voor opnieuw proberen in alle toepassingen en query's.
    • Implementeer logica voor opnieuw proberen in opgeslagen procedures en ETL-pijplijnen.
    • Voeg retry-logica met een vertraging toe aan pipelines of apps om tijdelijke conflicten af te handelen.
      • Gebruik exponentieel uitstel om stormen te voorkomen die tijdelijke netwerkonderbrekingen verergeren. Voor meer informatie, zie Herhalingspatroon.
  • Schrijf-schrijfconflicten met de Fabric Data Warehouse-achtergrondservice voor gegevenscompressie zijn mogelijk, maar worden meestal voorkomen door de functie voor het comprimeren van gegevens.

Blokkering van tabel- en parquet-bestanden

Conflicten van twee of meer gelijktijdige transacties die een of meer rijen in een tabel bijwerken, worden aan het einde van de transactie geëvalueerd. De eerste transactie die moet worden doorgevoerd, wordt voltooid en de andere transacties worden teruggedraaid met een geretourneerde fout. Deze conflicten worden geëvalueerd op tabelniveau en niet op het niveau van het afzonderlijke Parquet-bestand.

INSERT-instructies maken altijd nieuwe Parquet-bestanden, wat betekent dat er minder conflicten zijn met andere transacties, met uitzondering van DDL, omdat het schema van de tabel kan worden gewijzigd.

Beperkingen

  • Gedistribueerde transacties worden bijvoorbeeld BEGIN DISTRIBUTED TRANSACTIONniet ondersteund.
  • ALTER TABLE wordt niet ondersteund binnen een expliciete transactie.
  • Opslagpunten worden niet ondersteund.
  • Benoemde transacties worden niet ondersteund.
  • Gemarkeerde transacties worden niet ondersteund.
  • Op dit moment is er beperkte T-SQL-functionaliteit in het magazijn. Zie het T-SQL-bereik in Fabric Data Warehouse voor een lijst met T-SQL-opdrachten die momenteel niet beschikbaar zijn.
  • Als een transactie gegevens invoegt in een lege tabel en een SELECT uitgeeft voordat deze wordt teruggedraaid, kunnen de automatisch gegenereerde statistieken nog steeds de niet-verzonden gegevens weerspiegelen, waardoor onnauwkeurige statistieken ontstaan. Onnauwkeurige statistieken kunnen leiden tot niet-geoptimaliseerde queryplannen en uitvoeringstijden. Als u een transactie terugdraait met SELECTs na een grote INSERT, werkt u statistieken bij voor de kolommen die in uw SELECT worden genoemd.

Gerelateerde inhoud

  • Last updated on