Beheben von Abfrageblockierungen in Fabric Data Warehouse

Gilt für:✅ Warehouse in Microsoft Fabric

Wenn Ihre Abfragen in Warehouse ungewöhnlich lange dauern oder hängen bleiben, ist eine mögliche Ursache die Sperrung. Sperrung tritt auf, wenn eine Sitzung eine Sperre enthält, die verhindert, dass andere Abfragen fortgesetzt werden.

In diesem Artikel erfahren Sie, wie Sie bestimmen, ob sich die Sperrung auf Ihre Arbeitsauslastung auswirkt und welche Aktionen Sie ausführen können.

Voraussetzungen

• Ein Warehouse mit aktiven Workloads.
• Die Mitgliedschaft in der Rolle des Viewer-Arbeitsbereichs ist die Mindestberechtigung zum Abfragen der dynamischen Verwaltungsansichten (DYNAMIC Management Views, DMVs) in diesem Artikel.
  • Weitere Informationen zur Problembehandlung mit DMVs finden Sie unter Überwachen von Verbindungen, Sitzungen und Anforderungen mithilfe von DMVs.

Schritt 1: Überprüfen, ob Abfragen auf Sperren warten

Überprüfen Sie zunächst, ob derzeit Abfragen auf Sperren warten.

Führen Sie die folgende Abfrage aus:

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

Wenn die Abfrage Zeilen zurückgibt, warten einige Sitzungen auf Ressourcen, die von anderen Sitzungen belegt werden. Jede Zeile gibt eine Sperranforderung an, die derzeit nicht erteilt werden kann.

Schritt 2: Identifizieren blockierter Abfragen

Überprüfen Sie als Nächstes, welche Abfragen blockiert werden und welche Sitzung sie blockiert.

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;

Diese Abfrage gibt Folgendes zurück:

• Die Sitzung, in der die blockierte Abfrage ausgeführt wird (session_id)
• Die Sitzung, die dies derzeit blockiert (blocking_session_id)
• Wie lange gewartet wurde (total_elapsed_timein Millisekunden)
• Gibt an, ob die Blockierungssitzung über eine geöffnete Transaktion verfügt (open_transaction_count)

Wenn eine Abfrage anzeigt, dass blocking_session_id ungleich null ist und open_transaction_count > 0, wartet sie auf eine andere Sitzung, die eine Sperre hält.

Schritt 3: Ermitteln Sie die blockierende Sitzung

Um zu verstehen, welche Ressource gesperrt ist, überprüfen Sie die Sperren, die derzeit von der Blockierungssitzung gehalten werden. Ersetzen Sie in der folgenden Beispielabfrage das zuvor identifizierte session_id durch <blocking_session_id>:

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

Verwenden Sie diese Abfrage, um Folgendes zu bestimmen:

• Für welche Ressourcen die blockierende Sitzung derzeit Sperren hält. Zum Beispiel können Sie sys.objects verwenden, um resource_associated_entity_id zu identifizieren, wo resource_type = OBJECT.
• Der Sperrmodus (z. B. Exklusiv (X), Schema-Modification (Sch-M))
• Gibt an, ob die Sperre mit einem DDL-Vorgang oder einer Statistikaktualisierung verknüpft ist (UPDSTATS)

Schritt 4: Suchen des blockierenden Transaktionsbesitzers

In vielen Fällen möchten Sie möglicherweise lieber den Eigentümer der blockierenden Transaktion bitten, seine Arbeit COMMIT oder ROLLBACK, anstatt die Sitzung zu beenden. Erwägen Sie die Verwendung von TRYCATCH Strukturen für die Fehlerbehandlung mit COMMIT oder ROLLBACK. Weitere Informationen finden Sie unter TRY... CATCH.

Sie können den Besitzer und die Abfrage identifizieren, die der Blockierungssitzung zugeordnet ist. Ersetzen Sie in der folgenden Beispielabfrage das <blocking_session_id> durch ein session_id, das Sie zuvor identifiziert haben:

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 ist der Eigentümer der blockierenden Sitzung.
• program_name ist die Anwendung, die die Sitzung initiiert hat. Der DMS_user Wert gibt den Fabric Portalabfrage-Editor an.
• command ist der Befehl, der zurzeit ausgeführt wird.

Sie können sich dann an den Eigentümer der Transaktion wenden, um sie zu bestätigen oder sie bei Bedarf zurückzurollen.

Schritt 5: Überprüfen, ob die blockierende Sitzung inaktiv ist oder nicht voranschreitet

Eine blockierende Sitzung könnte als aktiv erscheinen, macht jedoch tatsächlich keine Fortschritte.

Anzeichen für eine inaktive oder hängengebliebene Sitzung sind:

• status = 'sleeping' gibt an, dass keine aktive Abfrage ausgeführt wird.
• Suchen Sie nach einer last_request_start_time, die deutlich vor der aktuellen Zeit liegt und auf eine seit Langem offene Anfrage hinweist.
• Achten Sie auf einen total_elapsed_time-Wert, der sich zwischen den Prüfungen nicht erhöht, was auf eine hängende Sitzung hinweist.

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

• Wenn der Sitzungsstatus sleeping und open_transaction_count > 0 ist, hat die Sitzung eine offene Transaktion ohne aktive Abfrage – sie hält eine Sperre, ohne Arbeit auszuführen.
• Wenn die Sitzung in sys.dm_exec_requests angezeigt wird und total_elapsed_time zwischen den Überprüfungen weiterhin zunimmt, schreitet die Sitzung aktiv voran. Es kann sinnvoll sein, auf den Abschluss der Transaktion zu warten, anstatt sie zu beenden und ein Rollback zu erzwingen.

Schritt 6: Ergreifen von Maßnahmen zum Beheben der Blockierung

Wenn Sie die Blockierung nachgeschalteter Abfragen aufheben müssen, sollten Sie überlegen, ob eine Blockierungssitzung die folgenden Merkmale aufweist:

• Verfügt über eine geöffnete Transaktion
• Scheint im Leerlauf zu sein oder macht keinen Fortschritt
• Hält eine Sperrsperre (z. B. Exklusiv (X) oder Sch-M)

Wenn ja, kann ein Mitglied der Rolle „Admin-Arbeitsbereich“ eine Sitzung mit Folgendem beenden:

KILL <session_id>;

Der KILL Befehl sieht wie folgt aus:

• Beenden der Sitzung
• Zurücksetzen aller in der aktiven Transaktion dieser Sitzung durchgeführten Arbeiten
• Freigeben der Sperre
• Zulassen, dass nachgeschaltete Abfragen fortgesetzt werden

Schritt 7: Verhindern zukünftiger Sperrprobleme

So verhindern Sie ähnliche Probleme:

• Vermeiden Sie explizite Transaktionen offen zu lassen (BEGIN TRANSACTION ohne entsprechende COMMIT oder ROLLBACK).
• Halten Sie Transaktionen kurz. Führen Sie nur die erforderlichen Vorgänge innerhalb der Transaktion aus.
• Immer COMMIT oder ROLLBACK Transaktionen, wenn sie abgeschlossen sind.
• Planen Sie DDL-Vorgänge (z. B. ALTER TABLE) für Zeiten mit geringem Datenverkehr ein.

Proaktives Überwachen offener Transaktionen mithilfe von:

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;

Die regelmäßige Überwachung offener Transaktionen und das Eingreifen bei Bedarf trägt dazu bei, die Wahrscheinlichkeit von Blockierungsketten zu verringern.

Verwandte Inhalte

• Überwachen von Verbindungen, Sitzungen und Anforderungen mithilfe von DMVs
• Transaktionen in Fabric Data Warehouse
• Fehlerbehebung im Lager
• Abfrageeinblicke in Fabric Data Warehouse