Langsame SQL-Server-Anfragen mit Extended Events erfassen

Eine sporadisch langsame Anfrage ist nach ihrem Ende schwer zu untersuchen. Ein Plan aus einem anderen Lauf erklärt möglicherweise nicht, ob Prozessorarbeit, Lesen oder Warten die Zeit verbraucht hat. Eine gezielte Extended-Events-Sitzung kann Belege sichern, ohne sämtliche Details aller Anweisungen aufzuzeichnen.

Die konkrete Frage lautet hier: Welche abgeschlossenen Anfragen einer Datenbank dauern mindestens eine Sekunde? Das begrenzt die Erfassung und liefert Kandidaten für weitere Analyse. Das Beispiel gilt für eine klassische SQL-Server-Instanz. Datenbankbezogene Cloud-Sitzungen und deren Speicherziele brauchen andere Einstellungen.

Die Erfassung vor dem Start definieren

Prüfen Sie die Ereignismetadaten der tatsächlichen Instanz statt Einheiten aus Namen zu erraten.

SELECT object_name, name, type_name, description
FROM sys.dm_xe_object_columns
WHERE object_name IN (N'rpc_completed', N'sql_batch_completed')
  AND name IN (N'duration', N'cpu_time');

Bei den verwendeten RPC- und Batch-Abschlussereignissen ist duration in Mikrosekunden angegeben. 1.000.000 entspricht einer Sekunde. Andere Zeitfelder anderer Ereignisse müssen nicht dieselbe Einheit verwenden. Erhalten Sie die Einheit auch beim Export.

Die Sitzung filtert auf Datenbank-ID 5. Ersetzen Sie diese durch DB_ID der gewünschten Datenbank und den Windows-Pfad durch ein vorhandenes Verzeichnis mit Schreibrecht für das SQL-Server-Dienstkonto. Der Sitzungsname darf nicht bereits verwendet werden.

-- SQL Server instance example: replace database_id 5 and the file path.
CREATE EVENT SESSION AxialSlowRequestsDemo ON SERVER
ADD EVENT sqlserver.rpc_completed (
    ACTION(sqlserver.client_app_name, sqlserver.database_name,
           sqlserver.session_id, sqlserver.sql_text)
    WHERE ([duration] >= (1000000) AND [sqlserver].[database_id] = (5))
),
ADD EVENT sqlserver.sql_batch_completed (
    ACTION(sqlserver.client_app_name, sqlserver.database_name,
           sqlserver.session_id, sqlserver.sql_text)
    WHERE ([duration] >= (1000000) AND [sqlserver].[database_id] = (5))
)
ADD TARGET package0.event_file (
    SET filename = N'D:\XEvents\AxialSlowRequests.xel',
        max_file_size = (20), max_rollover_files = (4)
)
WITH (MAX_MEMORY = 4096 KB,
      EVENT_RETENTION_MODE = ALLOW_SINGLE_EVENT_LOSS,
      MAX_DISPATCH_LATENCY = 5 SECONDS,
      STARTUP_STATE = OFF);
ALTER EVENT SESSION AxialSlowRequestsDemo ON SERVER STATE = START;

RPC-Ereignisse erfassen beispielsweise Prozeduraufrufe eines Treibers, Batch-Ereignisse eingesandte SQL-Batches. Da Anwendungen unterschiedlich arbeiten, reduziert die Kombination eine offensichtliche Lücke. Die Ereignisse sind dadurch aber weder identisch noch dürfen ihre Zeiten ohne Beachtung des Umfangs beliebig addiert werden.

Dateigröße und Rollover begrenzen das Ziel. Ältere Dateien können beim Weiterschalten verschwinden; es handelt sich um ein Diagnosefenster, kein dauerhaftes Archiv. STARTUP_STATE OFF verhindert einen automatischen Neustart der vorübergehenden Untersuchung nach einem Serverneustart.

ALLOW_SINGLE_EVENT_LOSS erlaubt mögliche Ereignisverluste. Diese Erfassung ist deshalb kein exaktes Audit. Überwachen Sie Sitzungszustand und Verluste, wenn die Vollständigkeit für eine Aussage wichtig ist.

Belege für den nächsten Test lesen

Lesen Sie die Dateien über denselben Zielpfad.

SELECT object_name, CAST(event_data AS xml) AS EventXml
FROM sys.fn_xe_file_target_read_file(
    N'D:\XEvents\AxialSlowRequests*.xel', NULL, NULL, NULL
);

Das XML enthält Zeitstempel, ereignisspezifische Felder und ausgewählte Aktionen. Ordnen Sie Zeitstempel konsistent, üblicherweise als UTC, den Anwendungsprotokollen zu. Dauer, CPU, logische Lesezugriffe und Batch- beziehungsweise Anweisungstext müssen nach dem jeweiligen Ereignisschema interpretiert werden.

Lange Dauer bei wenig CPU spricht für weitere Untersuchung von Warten, Blockierungen, Speicherzugriffen oder anderen Verzögerungen. Sie identifiziert noch keine einzelne Ursache. Viele logische Lesezugriffe können unnötige Datenarbeit zeigen, hohe CPU einen Anlass zur Plan- und Ausdrucksanalyse liefern. Entscheidend sind Plan und Parameter des tatsächlich langsamen Aufrufs.

Abschlussereignisse erklären keine Anfrage, die noch immer läuft. Für ein aktives Problem müssen aktuelle Requests und Wartezustände zusätzlich gelesen werden. Netzwerk- und Darstellungszeit im Client gehören ebenfalls nicht zur SQL-Ausführungsdauer dieses Ereignisses.

SQL-Text kann sensible Literale und Anwendungsdaten enthalten. Begrenzen Sie Dateizugriff, erfasste Aktionen und Aufbewahrung. Ungeprüfte Rohdateien sollten nicht in breit zugängliche Supportdiskussionen gelangen.

Beenden und die Schlussfolgerung festhalten

Nach Reproduktion oder Ablauf des Zeitbudgets wird die temporäre Sitzung gestoppt und entfernt.

ALTER EVENT SESSION AxialSlowRequestsDemo ON SERVER STATE = STOP;
DROP EVENT SESSION AxialSlowRequestsDemo ON SERVER;

Das Entfernen der Definition löscht keine Ereignisdateien. Bewahren Sie die relevanten Belege auf und verwalten Sie die Dateien nach der festgelegten Frist. Ein zu breites Dateimuster darf bei einer späteren Analyse nicht unbemerkt alte andere Läufe einbeziehen.

Beginnen Sie nicht mit hochvolumigen Anweisungsereignissen und vollständigen Plänen für die ganze Instanz. Erweitern Sie nur zur Beantwortung einer konkreten offenen Frage und messen Sie den Aufwand. Auch ein scheinbar enger Filter kann bei einer Störung Tausende Anfragen treffen.

Notieren Sie Datenbank, Zeitraum, Schwelle, Ereignistypen, Verluste und Hypothese. Danach folgt eine gezielte Änderung oder die nächste notwendige Messung. Der Nutzen liegt in der überprüfbaren Erklärung einer echten langsamen Anfrage, nicht in einer zusätzlichen Trace-Datei.

Technische Referenzen: Microsoft Learn: Extended Events quick start · Microsoft Learn: CREATE EVENT SESSION · Microsoft Learn: Read event files.