Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Toegepast op:✅ SQL Analytics endpoint en Warehouse 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 invoegingen uitvoeren in meerdere tabellen, of in 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 op deze tabellen worden uitgevoerd, ze allemaal de wijzigingen hebben of geen van hen dat doet. 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
Fabric Data Warehouse behandelt deze schemawijzigingen bijvoorbeeld als één atomische eenheid:
-- Sample Syntax---
BEGIN TRAN;
ALTER TABLE <table_name> ADD <column_name> <type>;
ALTER TABLE <table_name> DROP COLUMN <column_name>;
COMMIT;
Als een statement in de transactie mislukt, worden alle schemawijzigingen automatisch teruggedraaid.
Fabric Data Warehouse ondersteunt het uitvoeren van het volgende binnen een expliciete transactie:
CREATE TABLEDROP TABLETRUNCATE TABLECTASsp_rename-
ALTER TABLEnull-kolommen toevoegen -
ALTER TABLEkolommen verwijderen -
ALTER TABLEtoevoegen of verwijderenPRIMARY KEY,UNIQUEenFOREIGN KEYbeperkingen met hetNOT ENFORCEDtrefwoord - Meerdere
ALTER TABLEinstructies -
ALTER TABLEop gedistribueerde tijdelijke tabellen
Ondersteuning voor transactie tussen databases
Warehouse in Microsoft Fabric ondersteunt transacties die zich over meerdere warehouses binnen dezelfde werkruimte uitstrekken, waaronder het lezen van het SQL-analyse-eindpunt van het Lakehouse. Zie Een SQL-query voor meerdere databases schrijven voor een voorbeeld.
Inzicht in vergrendelen en blokkeren 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.
| Statementtype | Vergrendeling genomen |
|---|---|
| DML | |
| SELECT | Schema-Stability (Sch-S) |
| INSERT | Intentie exclusief (IX) |
| DELETE | Intentie exclusief (IX) |
| UPDATE | Intentie exclusief (IX) |
| MERGE | Intentie 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-wijziging (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-wijziging (Sch-M) |
U kunt momenteel vergrendelingen opvragen 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 isolatie van momentopnamen zijn schrijf- of updateconflicten mogelijk. Zie Conflicten tussen schrijven en schrijven in Fabric Data Warehouse voor meer informatie.
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 schemawijziging (
Sch-M) vergrendelingen. Tijdens de tijd dat deze wordt vastgehouden, voorkomt deSch-Mvergrendeling alle gelijktijdige toegang tot de tabel totdat de vergrendeling wordt vrijgegeven. - Tijdens DML-bewerkingen (Data Manipulat Language) gebruikt de Database Engine schemastabiliteit (
Sch-S) vergrendelingen. Bewerkingen dieSch-Mvergrendelingen verkrijgen, worden geblokkeerd doorSch-Svergrendelingen. 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 zoalssys.tablesensys.objectsgekoppeld aan de doeltabel, voor de duur van de transactie. Hiermee blokkeert u gelijktijdigeSELECTinstructies voorsys.tablesensys.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.
- Hoewel DDL-instructies kunnen worden uitgevoerd binnen expliciete gebruikerstransacties (
BEGIN TRAN), moeten ze voorzichtig worden gebruikt bij gelijktijdige workloads. Vanwege het vergrendelingsgedrag kan DDL binnen een transactie gelijktijdige DML- of SELECT-bewerkingen op de betreffende tabellen blokkeren, evenals SELECT-query's in systeemcatalogusweergaven zoalssys.tablesofsys.objects. Als u potentiële vergrendelingsconflicten wilt bewaken en oplossen, gebruikt usys.dm_tran_locks. - Controleer vergrendelingen en conflicten in het magazijn.
- Gebruik sys.dm_tran_locks om de huidige vergrendelingen te controleren.
Inzicht in 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 gebruikmaakt van vergrendeling op tabelniveau. 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
UPDATEbewerkingenDELETEMERGEin dezelfde tabel.- Let zorgvuldig op
UPDATE,DELETEMERGEbewerkingen binnen transacties met meerdere stappen.
- Let zorgvuldig op
- 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-service voor gegevenscompressie op de achtergrond zijn mogelijk, maar worden meestal voorkomen door de functie Data compaction preemption.
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 succesvol voltooid en de andere transacties worden teruggedraaid met een foutmelding. 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, aangezien het schema van de tabel kan veranderen.
Beperkingen
- Gedistribueerde transacties worden bijvoorbeeld
BEGIN DISTRIBUTED TRANSACTIONniet ondersteund. - 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 T-SQL-surface area 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.