Einführung in SQL Server Extended Events
SQL Server Extended Events (Extended Events) ist ein allgemeines Ereignisbehandlungssystem für Serversysteme. Die Extended Events-Infrastruktur unterstützt die Korrelation von Daten aus SQL Server sowie unter bestimmten Umständen die Korrelation von Daten aus dem Betriebssystem und aus Datenbankanwendungen. Im zweiten Fall muss die Ausgabe von Extended Events an die Ereignisablaufverfolgung für Windows (Event Tracing for Windows, ETW) weitergeleitet werden, damit die Ereignisdaten mit Ereignisdaten aus dem Betriebssystem oder einer Anwendung korreliert werden können.
Alle Anwendungen weisen Ausführungspunkte auf, die sowohl innerhalb der Anwendung als auch außerhalb nützlich sind. In der Anwendung kann die asynchrone Verarbeitung in die Warteschlage eingereiht werden, wobei Informationen zugrunde gelegt werden, die bei der ersten Ausführung eines Tasks gesammelt wurden. Außerhalb der Anwendung stellen Ausführungspunkte Überwachungshilfsprogrammen Informationen zum Verhalten und zu den Leistungsmerkmalen der überwachten Anwendung zur Verfügung.
Extended Events unterstützt die Verwendung von Ereignisdaten außerhalb eines Prozesses. Diese Daten werden i. d. R. folgendermaßen verwendet:
Von Ablaufverfolgungstools wie der SQL-Ablaufverfolgung und dem Systemmonitor
Von Tools für die Protokollierung wie dem Windows-Ereignisprotokoll oder dem SQL Server-Fehlerprotokoll
Von Benutzern, die ein Produkt verwalten oder Anwendungen für ein Produkt entwickeln
Design und Funktionen von Extended Events
Das Design von Extended Events zeichnet sich durch die folgenden zentralen Aspekte aus:
Das Extended Events-Modul ist ereignisagnostisch. Daher kann das Modul jedes beliebige Ereignis an jedes beliebige Ziel binden, da es nicht durch den Ereignisinhalt eingeschränkt wird. Weitere Informationen zum Extended Events-Modul finden Sie unter SQL Server Extended Events-Modul.
Ereignisse werden von Ereignisconsumern getrennt, die in Extended Events als Ziele bezeichnet werden. Das bedeutet, dass jedes Ziel jedes Ereignis empfangen kann. Zusätzlich kann jedes ausgelöste Ereignis automatisch vom Ziel verarbeitet werden, das dann wiederum die Protokollierung ausführen oder zusätzlichen Ereigniskontext bereitstellen kann. Weitere Informationen finden Sie unter SQL Server Extended Events-Ziele.
Ereignisse unterscheiden sich von der Aktion, die ausgeführt werden soll, wenn ein Ereignis ausgelöst wird. Dies führt dazu, dass jede beliebige Aktion jedem beliebigen Ereignis zugeordnet werden kann.
Mithilfe von Prädikaten kann das Auslösen von Ereignissen dynamisch gefiltert werden, wodurch die Extended Events-Infrastruktur noch flexibler wird. Weitere Informationen finden Sie unter SQL Server Extended Events-Pakete.
Extended Events kann Ereignisdaten synchron generieren (und asynchron verarbeiten), wodurch eine flexible Lösung für die Ereignisbehandlung bereitgestellt wird. Außerdem bietet Extended Events die folgenden Funktionen:
Eine im gesamten Serversystem einheitliche Methode für die Ereignisbehandlung, wobei die Benutzer dennoch die Möglichkeit haben, einzelne Ereignisse für die Problembehandlung zu isolieren
Integration mit und Unterstützung von vorhandenen ETW-Tools
Einen vollständig konfigurierbaren Ereignisbehandlungsmechanismus auf Grundlage von Transact-SQL
Die Möglichkeit zur dynamischen Überwachung aktiver Prozesse mit minimaler Beeinträchtigung dieser Prozesse
Verwenden von Extended Events mit ETW
Wenn Sie Extended Events für die die Korrelation von Daten des Betriebssystems und von Datenbankanwendungen verwenden möchten, sollten Sie zunächst mit ETW vertraut sein. ETW kann entweder in Verbindung mit Extended Events oder als Extended Events-Ereignisconsumer verwendet werden. In den folgenden Themen erhalten Sie erste Hintergrundinformationen zu ETW:
Szenarien für die Verwendung von Extended Events
Sie können Extended Events für vielfältigste Szenarien im Zusammenhang mit Überwachung und Problembehandlung verwenden. Die folgenden Szenarien entsprechen einigen Situationen, in denen Extended Events wichtige Daten für die Lösung von Problemen bereitstellen kann:
Feststellen der Ursache von Kürzungen von Workingsets
Feststellen der Ursache von übermäßiger CPU-Nutzung
Feststellen der Ursache von Deadlocks
Korrelieren von Anforderungsaktivitäten mit Windows-ETW-Protokollen
Feststellen der Ursache von Kürzungen von Workingsets
Auf Ihrem Produktionsserver treten schwerwiegende Leistungsprobleme auf, die zu einem Timeout bei Clientanwendungen führen. Die Probleme scheinen nur vorübergehend aufzutreten, und nach 10-15 Minuten ist die Leistung wieder normal.
Sie untersuchen das SQL Server-Fehlerprotokoll und finden die folgenden Fehlermeldungen:
"Ein erheblicher Teil des SQL Server-Prozessarbeitsspeichers wurde ausgelagert. Dies kann zu einer Leistungseinbuße führen. Dauer: 300 Sekunden. Aktuelle Arbeitsspeichernutzung: 34%."
"IOCP-Überwachung stellt kein Ergebnis bereit."
.gif "Hinweis") Hinweis |
|---|
IOCP steht für "E/A-Abschlussport" (IO Completion Port). Dieser Portdienste-Benutzer sendet Anforderungen über das Netzwerk. Die Nachricht gibt an, dass der Abschlussport während der letzten Minute blockiert war. |
Sie vermuten, dass SQL Server nicht schnell genug auf den ungenügenden Arbeitsspeicher auf dem Server reagiert. Wenn Sie den Arbeitsspeicher mit dem Task-Manager überprüfen, scheint der auf dem Server verfügbare Arbeitsspeicher mehr aus ausreichend zu sein. Sie versuchen, von SQL Server Management Studio eine Verbindung mit der Datenbank herzustellen, aber für den Verbindungsversuch tritt ein Timeout auf. Sie können eine Verbindung mit dem Server herstellen, indem Sie an der Windows-Eingabeaufforderung den Befehl SQLCMD - A ausführen. Dadurch wird über die dedizierte Administratorverbindung (Dedicated Administrator Connection, DAC) eine Sitzung geöffnet.
Sie beschließen, Extended Events zu verwenden, um weitere Informationen zu erhalten. Sie erstellen eine Extended Events-Sitzung, die Folgendes bewirkt:
Es werden Ereignisse für ein Systemspeichersignal und eine Änderung des gesamten Serverspeichers hinzugefügt.
Die Ausgabe wird an ETW weitergeleitet. Diese Ausgabe wird in eine Datei geschrieben, die auf einem Laufwerk erstellt wird, das weder für die Auslagerungsdatei noch für SQL Server-Datenbankdateien verwendet wird.
Sie führen an der Windows-Eingabeaufforderung eine Anweisung aus, die eine Windows Kernel-ETW-Ereignisablaufverfolgung mit allen Speicherereignissen aktiviert. Sie lassen beide Ablaufverfolgungen einige Minuten lang laufen und schließen dann sowohl die Extended Events-Sitzung als auch die Windows Kernel-Ablaufverfolgung.
Sie verwenden tracerpt.exe, um sowohl die Windows-Ablaufverfolgung als auch die SQL Server-ETW-Ereignisablaufverfolgung zu korrelieren. Sie halten Ausschau nach einem Ereignis, das darauf hinweist, dass die Benachrichtigung über nicht ausreichenden Systemspeicher festgelegt wurde, finden aber keines. Stattdessen finden Sie eine hohe Anzahl von Seitenfehlern aus allen Prozessen auf dem Server. Sie untersuchen die Ereignisse, die der Auslagerung unmittelbar vorangegangen sind, und stellen fest, dass die Workingsets aller Prozesse in Folge einer Speicherbelegungsanforderung eines Treibers gekürzt wurden.
Feststellen der Ursache von übermäßiger CPU-Nutzung
Sie untersuchen eine übermäßige CPU-Nutzung auf dem Produktionssystem. Mithilfe verschiedener dynamischer Verwaltungssichten (Dynamic Management Views, DMVs) ermitteln Sie, ob die CPU-Nutzung durch auf dem System ausgeführte Abfragen verursacht wird. Dabei stellen Sie fest, dass es sich bei den meisten Abfragen um Ad-hoc-Benutzerabfragen handelt. Die mithilfe der DMVs ermittelten Informationen reichen für eine Problemdiagnose nicht aus.
Sie erstellen eine Extended Events-Sitzung, die Folgendes bewirkt:
Es werden Ereignisse zur Anweisungsvervollständigung mit Prädikaten für den CPU-Schwellenwert aktiviert.
Es wird eine Aktion bereitgestellt, mit der der Abfrageplan nur ermittelt wird, wenn das Ereignis ausgelöst wird.
Alle gesammelten Daten werden in eine Datei geschrieben. Diese Datei befindet sich auf einem Laufwerk, das weder Protokoll- noch Datenbankdateien enthält.
Nach dem Start der Extended Events-Sitzung untersuchen Sie die Ausgabe und stellen fest, dass das CPU-Problem durch eine Datentypkonvertierung zwischen zwei verbundenen Tabellen mit gemeinsamen Spalten verursacht wird.
Feststellen der Ursache von Deadlocks
Benutzer haben Ihnen gemeldet, dass bestimmte Anwendungen Deadlockfehler zurückgeben. Zur möglichst effektiven Problembehandlung beschließen Sie, sich zunächst auf die Deadlocks zu konzentrieren, die am häufigsten auftreten. Sie erstellen eine Extended Events-Sitzung, die Folgendes bewirkt:
Die Deadlockereignisüberwachung wird für die Sitzung konfiguriert.
Es wird ein Ziel angegeben, für das die Aggregation auf Grundlage eines Bezeichners für den Deadlock ausgeführt wird.
Sie führen die Extended Events-Sitzung aus. Nachdem zusätzliche Deadlocks gemeldet wurden, können Sie aggregierte Deadlockinformationen sowie das vollständige XML-Deadlockdiagramm pro Quelle abrufen. Anhand dieser Informationen können Sie die am häufigsten auftretenden Deadlocks ermitteln und mit der Erarbeitung einer Lösung beginnen.
Korrelieren von Anforderungsaktivitäten mit Windows-ETW-Protokollen
Sie untersuchen den Grund für die Verlangsamung einer Anwendung auf dem Produktionsserver und können die Ursache auf eine lange Dauer von Lesevorgängen auf Datenträgern eingrenzen. Sie erstellen eine Extended Events-Sitzung, die Folgendes bewirkt:
Lesevorgänge auf Datenträgern werden als Sitzungsereignis hinzugefügt.
Die gesammelten Daten werden an ETW gesendet.
Nach dem Start der Extended Events-Sitzung führen Sie eine Windows Kernel-ETW-Ereignisablaufverfolgung aus. Nach 10 Minuten beenden Sie beide Sitzungen.
Sie verwenden tracerpt.exe, um die Windows-Ablaufverfolgung und die SQL-ETW-Ereignisablaufverfolgung zusammenzuführen. Anhand dieser zusammengeführten Ablaufverfolgung können Sie die Leseanforderungen von SQL Server an den Windows-Kernel korrelieren und nachverfolgen. Diese Analyse ergibt, dass eine lange Verzögerung eintritt, bevor die E/A-Anforderung an SQL Server zurückgegeben wird. Auf Grundlage dieser Informationen können Sie abschließend ermitteln, dass das E/A-Problem im physischen E/A-Pfad liegt.
Siehe auch