Feilsøk spørringsblokkering i Fabric datalager

Gjelder for:✅ Lager i Microsoft Fabric

Hvis spørringene dine i Warehouse tar uvanlig lang tid å kjøre eller virker fastlåst, kan en mulig årsak være låsing. Låsing oppstår når en økt har en lås som hindrer andre spørringer i å fortsette.

Denne artikkelen viser deg hvordan du kan avgjøre om låsing påvirker arbeidsmengden din, og hvilke tiltak du kan iverksette.

Tips

Lageret bruker låsing på tabellnivå. Enhver DML-operasjon får en lås på hele tabellen, uavhengig av hvor mange rader som påvirkes. Denne oppførselen er annerledes enn SQL Server, som støtter rad- og sidenivå-låser.

Forutsetninger

Steg 1: Sjekk om spørringer venter på låser

Start med å sjekke om noen forespørsler venter på låser.

Kjør følgende spørring:

SELECT
    request_session_id,
    resource_type,
    resource_description,
    request_mode,
    request_status
FROM sys.dm_tran_locks
WHERE request_status = 'WAIT';

Hvis spørringen returnerer rader, venter noen økter på ressurser som holdes av andre økter. Hver rad indikerer en låseforespørsel som for øyeblikket ikke kan innvilges.

Tips

Visningen sys.dm_tran_locks kan returnere et stort antall rader som gitte låser. Filtrering etter request_status = 'WAIT' fokuserer på de øktene som er blokkert.

Trinn 2: Identifiser blokkerte spørringer

Sjekk deretter hvilke spørringer som er blokkert og hvilken økt som blokkerer dem.

SELECT
    session_id,
    status,
    blocking_session_id,
    wait_type,
    total_elapsed_time,
    open_transaction_count
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;

Dette spørsmålet gir:

  • Økten som kjører den blokkerte spørringen (session_id)
  • Økten blokkerer det for øyeblikket (blocking_session_id)
  • Hvor lenge den har ventet (total_elapsed_time, i millisekunder)
  • Om blokkeringssesjonen har en åpen transaksjon (open_transaction_count)

Hvis en spørring viser blocking_session_id at er ikke-null og open_transaction_count > 0, venter den på en annen økt som holder en lås.

Steg 3: Finn blokkeringsøkten

For å forstå hvilken ressurs som er låst, inspiser låsene som blokkeringsøkten for øyeblikket har. Bytt ut en session_id du nevnte tidligere i stedet for <blocking_session_id> følgende eksempelspørsmål:

SELECT
    request_session_id,
    resource_type,
    resource_associated_entity_id,
    request_mode,
    request_status
FROM sys.dm_tran_locks
WHERE
    request_status = 'GRANT'
    AND request_session_id = <blocking_session_id>;

Bruk denne spørringen for å finne ut av:

  • Hvilke ressurser blokkeringsøkten for øyeblikket låser seg på. For eksempel kan du bruke sys.objects for å identifisere hvor resource_associated_entity_id .resource_type = OBJECT
  • Låsemodusen (for eksempel Eksklusiv (X), Schema-Modification (Sch-M))
  • Enten låsen er relatert til en DDL-operasjon eller statistikkoppdatering (UPDSTATS)

Bemerkning

Statistikkrelaterte låser (som de fra UPDSTATS) forekommer også i sys.dm_tran_locks. Schema-Modification (Sch-M) og Eksklusive (X) låser er de vanligste blokkeringene, men enhver låsetype kan blokkere en konfliktfylt forespørsel (for eksempel Sch-S blokkeringer Sch-M).

Trinn 4: Finn eieren av blokkeringstransaksjonen

I mange tilfeller foretrekker du kanskje å spørre eieren av blokkeringstransaksjonen om COMMIT eller ROLLBACK deres arbeid i stedet for å avslutte økten. Vurder å bruke TRYCATCH strukturer for feilhåndtering med COMMIT eller ROLLBACK. For mer informasjon, se TRY... TA IMOT.

Du kan identifisere eieren og søke knyttet til blokkeringsøkten. Bytt ut en session_id du nevnte tidligere i stedet for <blocking_session_id> følgende eksempelspørsmål:

SELECT
    r.session_id,
    s.login_name,
    s.program_name,
    r.status,
    r.blocking_session_id,
    r.command,
    r.total_elapsed_time,
    s.last_request_start_time,
    s.last_request_end_time
FROM sys.dm_exec_requests r
JOIN sys.dm_exec_sessions s
    ON r.session_id = s.session_id
WHERE r.session_id = <blocking_session_id>;
  • login_name er eieren av blokkeringsøkten.
  • program_name er applikasjonen som startet økten. Verdien DMS_user angir Fabric portal-spørringseditoren.
  • command er kommandoen som for øyeblikket kjøres.

Du kan deretter kontakte eieren av transaksjonen for å forplikte eller rulle den tilbake om nødvendig.

Steg 5: Sjekk om blokkingsøkten er inaktiv eller ikke utvikler seg

En blokkeringsøkt kan virke aktiv, men gjør egentlig ingen fremgang.

Indikatorer på en inaktiv eller fastlåst økt inkluderer:

  • status = 'sleeping' indikerer at ingen aktiv spørring kjører.
  • Se etter en last_request_start_time som er betydelig tidligere enn i dag, noe som indikerer en langvarig åpen forespørsel.
  • Se etter en total_elapsed_time som ikke øker mellom sjekkene, noe som indikerer en fastlåst økt.
SELECT
    session_id,
    status,
    last_request_start_time,
    last_request_end_time,
    open_transaction_count
FROM sys.dm_exec_sessions
WHERE session_id = <blocking_session_id>;
  • Hvis sesjonsstatusen er sleeping og open_transaction_count > 0, har sesjonen en åpen transaksjon uten aktiv spørring – den holder en lås uten å gjøre arbeid.
  • Hvis økten dukker opp i sys.dm_exec_requests og total_elapsed_time fortsetter å øke mellom sjekkene, er økten aktivt i gang. Det kan være bedre å vente til transaksjonen er fullført i stedet for å avslutte den og tvinge frem en tilbakerulling.

Trinn 6: Ta grep for å løse blokkering

Bemerkning

Blokkeringssituasjoner løser seg ofte av seg selv når blokkeringsøkten fullfører sin transaksjon. Hvis arbeidsmengden din tåler forsinkelsen, er venting det tryggeste alternativet.

Hvis du trenger å oppheve blokkeringen av nedstrøms spørringer, vurder om en blokkeringsøkt har følgende egenskaper:

  • Har en åpen transaksjon
  • Ser ut til å være inaktiv eller ikke gå fremover
  • Holder en blokkerende lås (for eksempel Eksklusiv (X) eller Sch-M)

Hvis ja, kan et medlem av Admin-arbeidsområdet avslutte en økt ved å bruke:

KILL <session_id>;

Kommandoen KILL vil:

  • Avslutt økten
  • Rull tilbake alt arbeid gjort i den aktive transaksjonen i den økten
  • Lås opp låsen
  • La nedstrøms spørringer fortsette

Forsiktighet

Å avslutte en økt ruller tilbake alt uforpliktet arbeid utført av den økten. Denne handlingen kan angre dataendringer gjort av brukeren eller applikasjonen. Bruk dette alternativet kun når du er sikker på at det å avslutte transaksjonen ikke påvirker arbeidsmengden negativt.

Trinn 7: Forhindre fremtidige låseproblemer

For å hjelpe til med å forebygge lignende problemer:

  • Unngå å la eksplisitte transaksjoner stå åpne (BEGIN TRANSACTION uten en tilsvarende COMMIT eller ROLLBACK).
  • Hold transaksjonene kortvarige. Utfør kun nødvendige operasjoner innenfor transaksjonen.
  • Alltid COMMIT eller ROLLBACK transaksjoner når de er fullført.
  • Planlegg DDL-operasjoner (som ALTER TABLE) i lavtrafikkvinduer.

Overvåk åpne transaksjoner proaktivt ved å bruke:

SELECT
    session_id,
    login_name,
    open_transaction_count,
    program_name,
    status,
    blocking_session_id,
    last_request_start_time
FROM sys.dm_exec_sessions
WHERE open_transaction_count > 0;

Regelmessig overvåking av åpne transaksjoner og intervensjon når det er hensiktsmessig, bidrar til å redusere sannsynligheten for at blokkeringskjeder dannes.

Relatert innhold

  • Last updated on