Bei der Überwachung der Leistung oder der Fehlerbehebung bei einem Problem wie Systemlangsamkeit kann es erforderlich sein, Abfragen zu finden oder zu erfassen, die eine lange Dauer oder eine hohe CPU-Leistung haben oder während der Ausführung erhebliche E/A-Vorgänge generieren. Sie können die DMVs oder den Abfragespeicher verwenden, um Informationen zur Abfrageleistung abzurufen, aber die Informationen in beiden Quellen sind aggregiert. Die DMVs stellen die durchschnittliche CPU, E/A, Dauer usw. für eine Abfrage nur so lange dar, wie sie im Cache war. Der Abfragespeicher stellt auch durchschnittliche Metriken für zahlreiche Ressourcen bereit, die jedoch über ein definiertes Zeitfenster (z. B. 30 Minuten oder eine Stunde) aggregiert werden. Es gibt natürlich Überwachungslösungen von Drittanbietern, die Ihnen all dies und mehr bieten können (wie SentryOne), aber für diesen Beitrag wollte ich mich auf native Tools konzentrieren.
Wenn Sie die Abfrageleistung für einzelne Ausführungen verstehen möchten, um die genaue Abfrage oder Gruppe von Abfragen zu lokalisieren, die ein Problem darstellen könnten, ist die einfachste Option die Verwendung von erweiterten Ereignissen. Und eine der schnellsten Einstiegsmöglichkeiten ist die Verwendung von XEvent Profiler, das über SQL Server Management Studio (ab Version 17.3) verfügbar ist:
XEvent-Profiler in SSMS
Grundlegende Verwendung
Es gibt zwei Optionen für XEvent Profiler:Standard und TSQL. Um einen der beiden zu verwenden, doppelklicken Sie einfach auf den Namen. Hinter den Kulissen wird eine intern definierte Ereignissitzung erstellt (falls noch nicht vorhanden) und gestartet, und der Live Data Viewer wird sofort mit Fokus geöffnet. Beachten Sie, dass nach dem Start der Sitzung auch unter angezeigt wird Verwaltung | Erweiterte Ereignisse | Sitzungen. Angenommen, Sie haben Aktivität auf dem Server, sollten die Einträge innerhalb von fünf Sekunden oder weniger im Viewer angezeigt werden.
Live Data Viewer (nach Doppelklick zum Starten der Standardsitzung)
Die Standard- und TSQL-Sitzungen teilen sich einige Ereignisse, wobei der Standard insgesamt mehr hat. Hier ist eine Auflistung der jeweiligen Ereignisse:
Standard TSQL
sql_batch_starting sql_batch_starting
sql_batch_completed
rpc_starting
rpc_completed
logout logout
login login
existing_connection existing_connection
attention Wenn Sie Informationen zur Abfrageausführung verstehen möchten, z. B. wie lange die Ausführung der Abfrage gedauert hat oder wie viel I/O sie verbraucht hat, ist Standard aufgrund der beiden abgeschlossenen Ereignisse die bessere Option. Für beide Sitzungen besteht der einzige Filter darin, Systemabfragen für Batch-, RPC- und Aufmerksamkeitsereignisse auszuschließen.
Anzeigen und Speichern von Daten
Wenn wir die Standardsitzung starten und einige Abfragen ausführen, sehen wir im Viewer das Ereignis, den Abfragetext und andere nützliche Informationen wie cpu_time, logical_reads und duration. Einer der Vorteile der Verwendung von rpc_completed und sql_batch_completed besteht darin, dass der Eingabeparameter angezeigt wird. In einem Fall, in dem eine gespeicherte Prozedur große Leistungsschwankungen aufweist, kann das Erfassen des Eingabeparameters äußerst nützlich sein, da wir eine Ausführung, die länger dauert, mit einem bestimmten Wert abgleichen können, der an die gespeicherte Prozedur übergeben wird. Um einen solchen Parameter zu finden, müssen wir die Daten nach Dauer sortieren, was wir nicht tun können, wenn der Datenfeed aktiv ist. Um irgendwelche Analysen durchführen zu können, muss der Datenfeed gestoppt werden.
Beenden des Datenfeeds im Live Viewer
Jetzt, da meine Abfragen nicht mehr verschwommen vorbeirollen, kann ich auf die Dauerspalte klicken, um meine Ereignisse zu sortieren. Wenn ich das erste Mal klicke, wird es in aufsteigender Reihenfolge sortiert, und weil ich faul bin und nicht nach unten scrollen möchte, klicke ich erneut, um in absteigender Reihenfolge zu sortieren.
Ereignisse nach absteigender Dauer sortiert
Jetzt kann ich alle Ereignisse sehen, die ich in der Reihenfolge von der höchsten bis zur niedrigsten Dauer erfasst habe. Wenn ich nach einer bestimmten gespeicherten Prozedur suchte, die langsam war, konnte ich entweder nach unten scrollen, bis ich sie fand (was schmerzhaft sein könnte), oder ich konnte die Daten gruppieren oder filtern. Das Gruppieren ist hier einfacher, da ich den Namen der gespeicherten Prozedur kenne.
Der Objektname wird im oberen Teil des Viewers angezeigt, aber wenn Sie auf ein beliebiges rpc_completed-Ereignis klicken, werden alle erfassten Elemente im Detailbereich angezeigt. Klicken Sie mit der rechten Maustaste auf object_name, wodurch es hervorgehoben wird, und wählen Sie Spalte in Tabelle anzeigen aus.
Objektname zur Datenanzeige hinzufügen
Im oberen Bereich kann ich jetzt mit der rechten Maustaste auf object_name klicken und Group by this Column auswählen. Wenn ich die Events unter usp_GetPersonInfo expandiere und dann wieder nach Dauer sortiere, sehe ich jetzt, dass die Ausführung mit PersonID=3133 die höchste Dauer hatte.
Ereignisse gruppiert nach Objektname, usp_GetPersonInfo sortiert nach absteigender Dauer
Um die Daten zu filtern:Verwenden Sie entweder die Schaltfläche Filter…, die Menüoption (Erweiterte Ereignisse | Filter…) oder STRG + R, um ein Fenster zu öffnen, um die Ergebnismenge basierend auf den verschiedenen angezeigten Feldern zu reduzieren. In diesem Fall haben wir nach object_name =usp_GetPersonInfo gefiltert, aber Sie können auch nach Feldern wie server_principal_name oder client_app_name filtern, da diese erfasst wurden.
Es sei darauf hingewiesen, dass weder die Standard- noch die TSQL-Sitzung in eine Datei schreiben. Tatsächlich gibt es für keine der Ereignissitzungen ein Ziel (wenn Sie nicht wussten, dass Sie eine Ereignissitzung ohne Ziel erstellen können, wissen Sie es jetzt). Wenn Sie diese Daten zur weiteren Analyse speichern möchten, müssen Sie einen der folgenden Schritte ausführen:
- Stoppen Sie die Datenzufuhr und speichern Sie die Ausgabe in einer Datei über das Menü "Erweiterte Ereignisse" (Export to | XEL File…)
- Stoppen Sie die Datenzufuhr und speichern Sie die Ausgabe in einer Tabelle in einer Datenbank über das Menü „Erweiterte Ereignisse“ (Exportieren nach | Tabelle…)
- Ändern Sie die Ereignissitzung und fügen Sie die Ereignisdatei als Ziel hinzu.
Option 1 ist meine Empfehlung, da sie eine Datei auf dem Datenträger erstellt, die Sie für andere freigeben und später in Management Studio zur weiteren Analyse überprüfen können. Innerhalb von Management Studio haben Sie die Möglichkeit, nicht relevante Daten herauszufiltern, nach einer oder mehreren Spalten zu sortieren, die Daten zu gruppieren und Berechnungen (z. B. Durchschnittswerte) durchzuführen. Sie können dies tun, wenn die Daten eine Tabelle sind, aber Sie müssen die TSQL schreiben; Die Analyse der Daten in der Benutzeroberfläche ist einfacher und schneller.
Ändern der XEvent Profiler-Sitzungen
Sie können die Standard- und TSQL-Ereignissitzungen ändern, und die von Ihnen vorgenommenen Änderungen bleiben auch nach Instanzneustarts erhalten. Wenn die Ereignissitzungen jedoch gelöscht werden (nachdem Sie Änderungen vorgenommen haben), werden sie auf die Standardeinstellungen zurückgesetzt. Wenn Sie feststellen, dass Sie ständig dieselben Änderungen vornehmen, schlage ich vor, dass Sie die Änderungen per Skript ausführen und eine neue Ereignissitzung erstellen, die auch nach Neustarts bestehen bleibt. Wenn wir uns beispielsweise die bisher erfasste Ausgabe ansehen, können wir sehen, dass sowohl Ad-hoc-Abfragen als auch gespeicherte Prozeduren ausgeführt wurden. Und obwohl es großartig ist, dass ich die verschiedenen Eingabeparameter für die gespeicherten Prozeduren sehen kann, sehe ich nicht die einzelnen Anweisungen, die mit diesem Satz von Ereignissen ausgeführt werden. Um diese Informationen zu erhalten, müsste ich das Ereignis sp_statement_completed hinzufügen.
Beachten Sie, dass sowohl die Standard- als auch die TSQL-Ereignissitzungen so konzipiert sind, dass sie leicht sind. Die Statement_Completed-Ereignisse werden häufiger ausgelöst als die Batch- und RPC-Ereignisse, daher kann es zu mehr Overhead kommen, wenn diese Ereignisse Teil einer Ereignissitzung sind. Bei der Verwendung von Anweisungsereignissen sehr empfehlen, zusätzliche Prädikate aufzunehmen. Zur Erinnerung:Die rpc- und Batch-Ereignisse filtern nur Systemabfragen heraus – es gibt kein anderes Prädikat. Im Allgemeinen empfehle ich auch zusätzliche Prädikate für diese Ereignisse, insbesondere für eine hochvolumige Arbeitslast.
Wenn Sie sich Sorgen darüber machen, ob die Ausführung der Standard- oder TSQL-Sitzungen zu Leistungseinbußen auf Ihrem System führt, verstehen Sie, dass der Live Data Viewer die Verbindung trennt, wenn er zu viel Overhead auf dem System verursacht. Dies ist eine große Sicherheit, aber ich würde trotzdem nachdenklich sein, wenn ich diese Event-Sessions verwende. Ich glaube, sie sind ein fantastischer erster Schritt zur Fehlerbehebung, insbesondere für diejenigen, die neu bei SQL Server oder Extended Events sind. Wenn Sie jedoch den Live Data Viewer geöffnet haben und sich von Ihrem Computer entfernen, wird die Ereignissitzung weiter ausgeführt . Durch das Stoppen oder Schließen des Live Data Viewer wird die Ereignissitzung beendet, was ich empfehle, wenn Sie mit Ihrer Datenerfassung oder Fehlerbehebung fertig sind.
Erstellen Sie für Ereignissitzungen, die Sie über einen längeren Zeitraum ausführen möchten, separate Ereignissitzungen, die in das Ziel event_file schreiben und über geeignete Prädikate verfügen. Wenn Sie weitere Informationen zu den ersten Schritten mit Extended Events benötigen, sehen Sie sich die Sitzung an, die ich letztes Jahr auf der SQLBits über die Migration von Profiler zu Extended Events gehalten habe.
