Felsöka frågeblockering i Fabric Data Warehouse

gäller för:✅ Warehouse i Microsoft Fabric

Om dina frågor i Warehouse tar ovanligt lång tid att köras eller verkar ha fastnat, kan en möjlig orsak vara låsning. Låsning sker när en session har ett lås som hindrar andra frågor från att fortsätta.

Den här artikeln visar hur du avgör om låsning påverkar din arbetsbelastning och vilka åtgärder du kan vidta.

Förutsättningar

• Ett lager med aktiva arbetsbelastningar.
• Medlemskap i arbetsyterollen Viewer är den lägsta behörighetsnivån för att fråga de dynamiska hanteringsvyer (DMV:er) som beskrivs i den här artikeln.
  • Mer information om felsökning med DMV:er finns i Övervaka anslutningar, sessioner och begäranden med DMV:er.

Steg 1: Kontrollera om frågor väntar på lås

Börja med att kontrollera om några databasfrågor just nu blockeras av lås.

Kör följande fråga:

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

Om frågan returnerar rader väntar vissa sessioner på resurser som innehas av andra sessioner. Varje rad anger en låsbegäran som för närvarande inte kan beviljas.

Steg 2: Identifiera blockerade frågor

Kontrollera sedan vilka frågor som blockeras och vilken session som blockerar 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;

Den här frågan returnerar:

• Sessionen som kör den blockerade frågan (session_id)
• Sessionen blockerar den för närvarande (blocking_session_id)
• Hur länge det har väntat (total_elapsed_timei millisekunder)
• Om blockeringssessionen har en öppen transaktion (open_transaction_count)

Om en fråga visar att blocking_session_id inte är noll och open_transaction_count > 0, väntar den på en annan session som har ett lås.

Steg 3: Hitta den blockerande sessionen

För att förstå vilken resurs som är låst kontrollerar du lås som för närvarande innehas av blockeringssessionen. Ersätt en session_id du identifierade tidigare med <blocking_session_id> i följande exempelfråga:

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

Använd den här frågan för att avgöra:

• Vilka resurser blockeringssessionen för närvarande innehåller lås på. Du kan till exempel använda sys.objects för att identifiera resource_associated_entity_id där resource_type = OBJECT.
• Låsläget (till exempel Exklusivt (X), Schema-Modification (Sch-M))
• Om låset är relaterat till en DDL-åtgärd eller statistikuppdatering (UPDSTATS)

Steg 4: Hitta den blockerande transaktionsägaren

I många fall kanske du föredrar att be ägaren till den blockerande transaktionen att COMMIT eller ROLLBACK sitt arbete i stället för att avsluta sessionen. Överväg att använda TRYCATCH strukturer för felhantering med COMMIT eller ROLLBACK. Mer information finns i TRY... CATCH.

Du kan identifiera ägaren och frågan som är associerad med blockeringssessionen. Ersätt en session_id du identifierade tidigare med <blocking_session_id> i följande exempelfråga:

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 är ägare till blockeringssessionen.
• program_name är programmet som initierade sessionen. Värdet DMS_user anger Fabric-portalens frågeredigerare.
• command är kommandot som körs för närvarande.

Du kan sedan kontakta ägaren av transaktionen för att genomföra eller återställa den om det är lämpligt.

Steg 5: Kontrollera om blockeringssessionen är inaktiv eller inte pågår

En blockeringssession kan verka aktiv men gör faktiskt inte några framsteg.

Indikatorer för en inaktiv eller stoppad session är:

• status = 'sleeping' anger att ingen aktiv fråga körs.
• Leta efter en last_request_start_time som är betydligt tidigare än den aktuella tiden, vilket indikerar en långlivad öppen begäran.
• Leta efter en total_elapsed_time som inte ökar mellan kontroller, vilket indikerar en stoppad 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>;

• Om sessionens status är sleeping och open_transaction_count > 0 har sessionen en öppen transaktion utan aktiv fråga – den håller ett lås utan att utföra något arbete.
• Om sessionen visas i sys.dm_exec_requests och total_elapsed_time fortsätter att öka mellan kontrollerna, pågår sessionen aktivt. Det kan vara bättre att vänta tills transaktionen har slutförts i stället för att avsluta den och tvinga fram en återställning.

Steg 6: Vidta åtgärder för att lösa blockering

Om du behöver avblockera underordnade frågor bör du överväga om en blockeringssession har följande egenskaper:

• Har en öppen transaktion
• Verkar inaktiv eller gör inga framsteg
• Håller ett blockeringslås (till exempel Exklusivt (X) eller Sch-M)

I så fall kan en medlem av rollen Administratörsarbetsyta avsluta en session med hjälp av:

KILL <session_id>;

Kommandot KILL kommer att:

• Avsluta sessionen
• Återställ allt arbete som utförts i den sessionens aktiva transaktion
• Släpp låset
• Tillåt att underordnade frågor fortsätter

Steg 7: Förhindra problem med framtida låsning

Så här förhindrar du liknande problem:

• Undvik att lämna explicita transaktioner öppna (BEGIN TRANSACTION utan motsvarande COMMIT eller ROLLBACK).
• Håll transaktionerna kortvariga. Utför endast nödvändiga åtgärder i transaktionen.
• COMMIT eller ROLLBACK alltid transaktioner när de är slutförda.
• Schemalägg DDL-åtgärder (till exempel ALTER TABLE) under fönster med låg trafik.

Övervaka öppna transaktioner proaktivt med hjälp av:

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;

Att regelbundet övervaka öppna transaktioner och ingripa när det är lämpligt bidrar till att minska sannolikheten för att blockeringskedjor bildas.

Relaterat innehåll

• Övervaka anslutningar, sessioner och begäranden med DMV:er
• Transaktioner i Fabric Data Warehouse
• Felsöka lagret
• Fråga insikter i Fabric Data Warehouse