Transaktioner i lagertabeller i Microsoft Fabric

  • Artikel

Gælder for: SQL Analytics-slutpunkt og warehouse i Microsoft Fabric

På samme måde som med deres funktionsmåde i SQL Server giver transaktioner dig mulighed for at styre bekræftelse eller annullering af læse- og skriveforespørgsler.

Du kan ændre data, der er gemt i tabeller på et lager, ved hjælp af transaktioner for at gruppere ændringer sammen.

  • Du kan f.eks. bekræfte indsættelser i tabeller med flere tabeller eller ingen af tabellerne, hvis der opstår en fejl. Hvis du ændrer oplysninger om en indkøbsordre, der påvirker tre tabeller, kan du gruppere disse ændringer i en enkelt transaktion. Det betyder, at når disse tabeller forespørges, har de enten alle ændringerne, eller ingen af dem gør. Transaktioner er en almindelig praksis, når du har brug for at sikre, at dine data er ensartede på tværs af flere tabeller.

Transaktionsegenskaber

De samme transaktionsfunktioner understøttes i SQL Analytics-slutpunktet i Microsoft Fabric, men til skrivebeskyttede forespørgsler.

Transaktioner kan også bruges til sekventielle SELECT-sætninger for at sikre, at de involverede tabeller alle har data fra samme tidspunkt. Hvis der f.eks. tilføjes nye rækker i en tabel af en anden transaktion, påvirker de nye rækker ikke SELECT-forespørgslerne i en åben transaktion.

Vigtigt

Det er kun niveauet for snapshotisolation, der understøttes i Microsoft Fabric. Hvis du bruger T-SQL til at ændre dit isolationsniveau, ignoreres ændringen på forespørgselsudførelsestidspunktet, og der anvendes snapshotisolation.

Understøttelse af forespørgselstransaktion på tværs af databaser

Warehouse i Microsoft Fabric understøtter transaktioner, der strækker sig over databaser, der er inden for det samme arbejdsområde, herunder læsning fra SQL Analytics-slutpunktet for Lakehouse. Hver Lakehouse har ét skrivebeskyttet SQL-analyseslutpunkt. Hvert arbejdsområde kan have mere end ét lakehouse.

DDL-understøttelse i transaktioner

Warehouse i Microsoft Fabric understøtter DDL, f.eks. CREATE TABLE i brugerdefinerede transaktioner.

Låse til forskellige typer sætninger

Denne tabel indeholder en liste over, hvilke låse der bruges til forskellige typer transaktioner. Alle låse er på tabelniveau:

Sætningstype Låsen er taget
VÆLG Skema-stabilitet (Sch-S)
INDSÆTTE Intent Exclusive (IX)
SLETTE Intent Exclusive (IX)
OPDATERING Intent Exclusive (IX)
KOPIÉR TIL Intent Exclusive (IX)
DDL Skemaændring (Sch-M)

Disse låse forhindrer konflikter, f.eks. en tabels skema, ændres, mens rækker opdateres i en transaktion.

Du kan i øjeblikket opbevare forespørgselslåse med DMV-sys.dm_tran_locks (Dynamic Management View).

Konflikter fra to eller flere samtidige transaktioner, der opdaterer en eller flere rækker i en tabel, evalueres i slutningen af transaktionen. Den første transaktion, der skal bekræftes, fuldføres, og de andre transaktioner annulleres med en fejl returneret. Disse konflikter evalueres på tabelniveau og ikke på det individuelle parquetfilniveau.

INSERT-sætninger opretter altid nye parquetfiler, hvilket betyder færre konflikter med andre transaktioner undtagen DDL, fordi tabellens skema kan ændres.

Transaktionslogføring

Transaktionslogføring i Warehouse i Microsoft Fabric er på parketfilniveau, fordi parketfiler er uforanderlige (de kan ikke ændres). En annullering resulterer i, at der peges tilbage på de forrige parquetfiler. Fordelene ved denne ændring er, at transaktionslogføring og annulleringer er hurtigere.

Begrænsninger

  • Distribuerede transaktioner understøttes ikke.
  • Lagringspunkter understøttes ikke.
  • Navngivne transaktioner understøttes ikke.
  • Markerede transaktioner understøttes ikke.
  • ALTER TABLE understøttes ikke i en eksplicit transaktion.
  • På nuværende tidspunkt er der begrænset T-SQL-funktionalitet i lageret. Se TSQL-overfladeområdet for at få en liste over T-SQL-kommandoer, der i øjeblikket ikke er tilgængelige.
  • Hvis en transaktion indeholder dataindsætning i en tom tabel og udsteder en SELECT, før den annulleres, kan den automatisk genererede statistik stadig afspejle de ikke-bekræftede data, hvilket medfører unøjagtige statistikker. Unøjagtige statistikker kan føre til ikke-optimerede forespørgselsplaner og kørselstider. Hvis du annullerer en transaktion med SELECTs efter et stort INSERT, skal du opdatere statistikkerne for de kolonner, der er nævnt i din SELECT.

Relateret indhold