Problemen met het blokkeren van query's in Fabric Data Warehouse oplossen

Van toepassing op:✅ Warehouse in Microsoft Fabric

Als het ongebruikelijk lang duurt voordat uw query's in Warehouse worden uitgevoerd of als ze vastlopen, is een mogelijke oorzaak het vergrendelen. Vergrendelen treedt op wanneer een sessie een vergrendeling bevat die voorkomt dat andere query's verdergaan.

In dit artikel wordt beschreven hoe u kunt bepalen of vergrendeling van invloed is op uw werkbelasting en welke acties u kunt ondernemen.

Prerequisites

• Een magazijn met actieve workloads.
• Lidmaatschap van de werkruimterol Viewer is de minimaal vereiste machtiging om de dynamische beheerweergaven (DMV's) in dit artikel op te vragen.
  • Zie Verbindingen, sessies en aanvragen bewaken met DMV's voor meer informatie over het oplossen van problemen met DMV's.

Stap 1: Controleren of query's wachten op vergrendelingen

Begin met te controleren of er momenteel query’s op vergrendelingen wachten.

Voer de volgende query uit.

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

Als de query rijen retourneert, wachten sommige sessies op resources die door andere sessies worden gehouden. Elke rij geeft een vergrendelingsaanvraag aan die momenteel niet kan worden verleend.

Stap 2: Geblokkeerde query's identificeren

Controleer vervolgens welke query's worden geblokkeerd en welke sessie deze blokkeert.

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;

Deze query retourneert:

• De sessie waarop de geblokkeerde query wordt uitgevoerd (session_id)
• De sessie blokkeert deze momenteel (blocking_session_id)
• Hoe lang er al wordt gewacht (total_elapsed_time, in milliseconden)
• Of de blokkerende sessie een geopende transactie heeft (open_transaction_count)

Als een query aangeeft dat blocking_session_id niet nul is en open_transaction_count > 0, wacht deze op een andere sessie die een vergrendeling vasthoudt.

Stap 3: De blokkeringssessie zoeken

Als u wilt weten welke resource is vergrendeld, controleert u de vergrendelingen die momenteel door de blokkerende sessie worden aangehouden. Vervang de <blocking_session_id> in de volgende voorbeeldquery door een session_id die u eerder hebt geïdentificeerd:

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

Gebruik deze query om het volgende te bepalen:

• Op welke resources de blokkerende sessie momenteel vergrendelingen heeft. U kunt bijvoorbeeld sys.objects gebruiken om de resource_associated_entity_id te identificeren waar de resource_type = OBJECT.
• De vergrendelingsmodus (bijvoorbeeld Exclusief (X), Schema-Modification (Sch-M))
• Of de vergrendeling is gerelateerd aan een DDL-bewerking of statistiekenupdate (UPDSTATS)

Stap 4: de eigenaar van de blokkerende transactie zoeken

In veel gevallen geeft u er mogelijk de voorkeur aan de eigenaar van de blokkerende transactie te vragen om COMMIT of ROLLBACK zijn of haar werk in plaats van de sessie te beëindigen. Overweeg structuren te gebruiken TRYCATCH voor foutafhandeling met COMMIT of ROLLBACK. Zie TRY...CATCH voor meer informatie.

U kunt de eigenaar en query identificeren die is gekoppeld aan de blokkeringssessie. Vervang een session_id die u eerder hebt geïdentificeerd door de <blocking_session_id> in de volgende voorbeeldquery:

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 is de eigenaar van de blokkeringssessie.
• program_name is de toepassing die de sessie heeft gestart. De DMS_user waarde geeft de Fabric portalquery-editor aan.
• command is de opdracht die momenteel wordt uitgevoerd.

Vervolgens kunt u contact opnemen met de eigenaar van de transactie om deze vast te leggen of terug te draaien, indien van toepassing.

Stap 5: Controleren of de blokkerende sessie inactief is of geen voortgang boekt

Een blokkerende sessie kan actief lijken, maar maakt in werkelijkheid geen voortgang.

Indicatoren van een niet-actieve of vastgelopen sessie zijn:

• status = 'sleeping' geeft aan dat er geen actieve query wordt uitgevoerd.
• Zoek naar een last_request_start_time aanvraag die aanzienlijk eerder is dan de huidige tijd, wat aangeeft dat er een open aanvraag met een lange levensduur is.
• Zoek naar een total_elapsed_time die tussen opeenvolgende controles niet toeneemt, wat duidt op een vastgelopen sessie.

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

• Als de sessiestatus sleeping en open_transaction_count > 0 is, heeft de sessie een open transactie zonder actieve query: de sessie houdt een vergrendeling vast zonder werk uit te voeren.
• Als de sessie in sys.dm_exec_requests wordt weergegeven en total_elapsed_time tussen de controles blijft toenemen, is de sessie actief bezig. Het is misschien beter om te wachten tot de transactie is voltooid in plaats van deze te beëindigen en een terugdraaiactie af te dwingen.

Stap 6: Actie ondernemen om blokkeringen op te lossen

Als u downstreamquery's wilt deblokkeren, moet u overwegen of een blokkeringssessie de volgende kenmerken heeft:

• Heeft een geopende transactie
• Lijkt inactief of maakt geen voortgang
• Houdt een blokkeringsvergrendeling vast (bijvoorbeeld Exclusief (X) of Sch-M)

Zo ja, dan kan een lid van de werkruimterol Beheerder een sessie beëindigen met behulp van:

KILL <session_id>;

Met de KILL opdracht wordt het volgende uitgevoerd:

• De sessie beëindigen
• Alle werkzaamheden die zijn uitgevoerd in de actieve transactie van die sessie terugdraaien
• De vergrendeling vrijgeven
• Downstreamquery's toestaan om door te gaan

Stap 7: Toekomstige vergrendelingsproblemen voorkomen

Om vergelijkbare problemen te voorkomen:

• Vermijd expliciete transacties open te laten (BEGIN TRANSACTION zonder een corresponderend COMMIT of ROLLBACK).
• Houd transacties met een korte levensduur. Voer alleen de benodigde bewerkingen binnen de transactie uit.
• Altijd COMMIT of ROLLBACK transacties wanneer deze zijn voltooid.
• DDL-bewerkingen (zoals ALTER TABLE) plannen tijdens vensters met weinig verkeer.

Open transacties proactief bewaken met behulp van:

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;

Regelmatig open transacties bewaken en tussenkomen wanneer dit van toepassing is, helpt de kans op blokkerende ketens te verminderen.

Verwante inhoud

• Verbindingen, sessies en aanvragen bewaken met DMV's
• Transacties in Fabric Data Warehouse
• Problemen met het magazijn oplossen
• Query-inzichten in Fabric Data Warehouse