Fejlsøg blokering af forespørgsler i Fabric data warehouse

Gælder for:✅ Warehouse i Microsoft Fabric

Hvis dine forespørgsler i Warehouse tager usædvanligt lang tid at køre eller virker fastlåste, er en mulig årsag låsning. Låsning opstår, når en session holder en lås, der forhindrer andre forespørgsler i at fortsætte.

Denne artikel viser dig, hvordan du kan afgøre, om låsning påvirker din arbejdsbyrde, og hvilke handlinger du kan tage.

Forudsætninger

• Et lager med aktive arbejdsbyrder.
• Medlemskab i Viewer-arbejdsområdets rolle er minimumstilladelsen til at forespørge de dynamiske administrationsvisninger (DMV'er) i denne artikel.
  • For mere information om fejlfinding med DMV'er, se Overvåg forbindelser, sessioner og anmodninger ved brug af DMV'er.

Trin 1: Tjek om forespørgsler venter på låse

Start med at tjekke, om der er nogen forespørgsler, der venter på låsene.

Kør følgende forespørgsel:

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

Hvis forespørgslen returnerer rækker, venter nogle sessioner på ressourcer, der holdes af andre sessioner. Hver række angiver en låsanmodning, der ikke kan imødekommes i øjeblikket.

Trin 2: Identificer blokerede forespørgsler

Tjek dernæst, hvilke forespørgsler der er blokeret, og hvilken session der blokerer 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;

Denne forespørgsel returnerer:

• Sessionen, der kører den blokerede forespørgsel (session_id)
• Sessionen blokerer det i øjeblikket (blocking_session_id)
• Hvor længe har den ventet (total_elapsed_time, i millisekunder)
• Om blokeringssessionen har en åben transaktion (open_transaction_count)

Hvis en forespørgsel viser blocking_session_id er forskellig fra nul og open_transaction_count > 0, venter den på en anden session, der holder en lås.

Trin 3: Find blokeringssessionen

For at forstå, hvilken ressource der er låst, inspicer låse, som blokeringssessionen i øjeblikket holder. Udskift et session_id eksempelspørgsmål, som du nævnte tidligere, med følgende <blocking_session_id> eksempelforespørgsel:

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>;

Brug denne forespørgsel til at bestemme:

• Hvilke ressourcer blokeringssessionen aktuelt holder låser på. For eksempel kan du bruge sys.objects til at identificere hvor resource_associated_entity_id .resource_type = OBJECT
• Låsetilstanden (for eksempel Eksklusiv (X), Schema-Modification (Sch-M))
• Uanset om låsen er relateret til en DDL-operation eller statistikopdatering (UPDSTATS)

Trin 4: Find ejeren af blokeringstransaktionen

I mange tilfælde foretrækker du måske at spørge ejeren af blokeringstransaktionen COMMIT eller ROLLBACK deres arbejde i stedet for at afslutte sessionen. Overvej at bruge TRYCATCH strukturer til fejlhåndtering med COMMIT eller ROLLBACK. For mere information, se TRY... FANG.

Du kan identificere ejeren og forespørgslen tilknyttet blokeringssessionen. Udskift et session_id eksempelspørgsmål, som du nævnte tidligere, med følgende <blocking_session_id> eksempelforespørgsel:

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 ejeren af blokeringssessionen.
• program_name er applikationen, der indledte sessionen. Værdien DMS_user angiver Fabric-portalforespørgselseditoren.
• command er kommandoen, der aktuelt kører.

Du kan derefter kontakte ejeren af transaktionen for at forpligte dig eller rulle den tilbage, hvis det er relevant.

Trin 5: Tjek om blokeringssessionen er inaktiv eller ikke fremskrider

En blokeringssession kan virke aktiv, men gør faktisk ikke fremskridt.

Indikatorer for en inaktiv eller fastlåst session inkluderer:

• status = 'sleeping' indikerer ingen aktiv forespørgsel kørende.
• Se efter en last_request_start_time periode, der er væsentligt tidligere end nutid, hvilket indikerer en langvarig åben anmodning.
• Se efter en total_elapsed_time der ikke stiger mellem tjek, hvilket indikerer en fastlåst session.

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 sessionens status er sleeping og open_transaction_count > 0, har sessionen en åben transaktion uden aktiv forespørgsel – den holder en lås uden at udføre arbejde.
• Hvis sessionen optræder i sys.dm_exec_requests og total_elapsed_time fortsætter med at stige mellem checks, skrider sessionen aktivt frem. Det kan være bedre at vente på, at transaktionen er fuldført, frem for at afslutte den og tvinge en rollback.

Trin 6: Tag handling for at løse blokeringen

Hvis du har brug for at fjerne blokeringen af downstream-forespørgsler, så overvej, om en blokeringssession har følgende karakteristika:

• Har en åben transaktion
• Ser ud til at være inaktiv eller ikke i gang
• Holder du en blokeringslås (for eksempel Eksklusiv (X) eller Sch-M)

Hvis ja, kan et medlem af Admin-arbejdsområdets rolle afslutte en session ved at bruge:

KILL <session_id>;

Kommandoen KILL vil:

• Afslut sessionen
• Rull alt arbejde udført i den aktive transaktion i den pågældende session tilbage
• Lås låsen op
• Lad downstream-forespørgsler fortsætte

Trin 7: Undgå fremtidige låseproblemer

For at hjælpe med at forhindre lignende problemer:

• Undgå at lade eksplicitte transaktioner stå åbne (BEGIN TRANSACTION uden en tilsvarende COMMIT eller ROLLBACK).
• Bevar kortlivede transaktioner. Udfør kun de nødvendige operationer inden for transaktionen.
• Altid COMMIT eller ROLLBACK transaktioner, når de er fuldført.
• Planlæg DDL-operationer (såsom ALTER TABLE) under lavtrafikvinduer.

Overvåg proaktivt åbne transaktioner ved at bruge:

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;

Regelmæssig overvågning af åbne transaktioner og indgriben, når det er relevant, hjælper med at mindske sandsynligheden for, at blokeringskæder dannes.

Relateret indhold

• Overvåg forbindelser, sessioner og anmodninger ved hjælp af DMV'er
• Transaktioner i Fabric data warehouse
• Fejlfinding af lageret
• Søg indsigter i Fabric data warehouse