Erkunden erweiterter Ereignisse

Abgeschlossen

Die Engine für erweiterte Ereignisse in Azure SQL ist ein schlankes und leistungsfähiges Überwachungssystem, mit dem Sie präzise Informationen über die Aktivität in Ihren Datenbanken und Servern erfassen können. Die Überwachungslösungen auf der Azure-Plattform ermöglichen es Ihnen, auf einfache Weise eine leistungsstarke Überwachung für Ihre Umgebung zu konfigurieren und automatisierte Reaktionen auf Fehlerbedingungen bereitzustellen.

Erweiterte Ereignisse basieren auf der Funktionalität von SQL Server Profiler, indem sie es Ihnen ermöglichen, Abfragen nachzuverfolgen und zusätzliche Daten (Ereignisse) verfügbar zu machen, die Sie überwachen können. Nachfolgend finden Sie einige Beispiele für Probleme, die Sie mit erweiterten Ereignissen beheben können:

• Problembehandlung bei Leistungsproblemen durch Blockierungs- und Deadlocksituationen
• Ermitteln zeitintensiver Abfragen
• Überwachen von DDL-Vorgängen (Data Definition Language)
• Protokollieren fehlender Spaltenstatistiken
• Beobachten der zu hohen Belegung von Arbeitsspeicher in der Datenbank
• Zeitintensive physische E/A-Vorgänge

Das Framework für erweiterte Ereignisse ermöglicht es Ihnen auch, die Menge der gesammelten Daten mithilfe von Filtern zu begrenzen, um den Mehraufwand der Datenerfassung zu reduzieren. Das Framework gestattet es Ihnen zudem, Ihr Leistungsproblem leichter zu identifizieren, indem Sie Ihren Fokus auf bestimmte Bereiche richten.

Im Folgenden finden Sie ein Beispiel einer Sitzung für erweiterte Ereignisse, die in Azure SQL-Datenbank erstellt wurde:

In der obigen Abbildung ist xe_deadlocks der Name einer Sitzung für erweiterte Ereignisse, die in der Datenbank AdventureWorks ausgeführt wird (auf der linken Seite der Abbildung). Der Zielknoten event_counter, der sich unter dem Knoten der Ereignissitzung befindet, zählt die Anzahl der Vorkommen der einzelnen Ereignisse in der Ereignissitzung. Um die Zieldaten im SSMS-Objekt-Explorer zu erkunden, können Sie mit der rechten Maustaste auf den Zielknoten klicken und dann Zieldaten anzeigen auswählen. SSMS zeigt die Daten an, die auf der linken Seite der Abbildung zu sehen sind, sowie die Anzahl der Ergebnisse für jedes Ereignis.

Weitere Informationen zu erweiterten Ereignissen in Azure SQL-Datenbank finden Sie unter Erweiterte Ereignisse in Azure SQL-Datenbank.

Was kann ich mit erweiterten Ereignissen überwachen?

Erweiterte Ereignisse decken den gesamte Oberflächenbereich von SQL Server ab und sind in vier Kanäle unterteilt, die die Zielgruppe eines Ereignisses definieren.

• Admin: Admin-Ereignisse sind für Endbenutzer und Administratoren gedacht. Die enthaltenen Ereignisse zeigen ein Problem innerhalb einer genau definierten Reihe von Aktionen an, die ein Administrator durchführen kann. Ein Beispiel hierfür ist die Generierung eines XML-Deadlock-Berichts, um die Grundursache des Deadlocks zu identifizieren.
• Operativ: Operative Ereignisse werden zur Analyse und Diagnose oder für allgemeine Probleme verwendet. Diese Ereignisse können verwendet werden, um eine Aktion oder Aufgabe auszulösen, die auf dem Vorkommen des Ereignisses basiert. Ein Beispiel für ein operatives Ereignis wäre eine Datenbank in einer Verfügbarkeitsgruppe, die ihren Zustand ändert, was auf einen Failover hinweisen würde.
• Analytisch: Analytische Ereignisse beziehen sich in der Regel auf Leistungsereignisse und werden in großen Mengen veröffentlicht. Die Ablaufverfolgung von gespeicherten Prozeduren oder die Ausführung von Abfragen wäre ein Beispiel für ein analytisches Ereignis.
• Debug: Debugereignisse sind nicht unbedingt vollständig dokumentiert, und Sie sollten sie nur bei der Problembehandlung in Verbindung mit dem Microsoft-Support verwenden.

Ereignisse werden zu Sitzungen hinzugefügt, die mehrere Ereignisse hosten können. Normalerweise werden mehrere Ereignisse in einer Sitzung gruppiert, um einen zusammengehörigen Satz von Informationen zu erfassen.

Sie können die folgende Abfrage ausführen, um eine Liste der verfügbaren Ereignisse, Aktionen und Ziele abzurufen:

SELECT
    obj.object_type,
    pkg.name AS [package_name],
    obj.name AS [object_name],
    obj.description AS [description]
FROM sys.dm_xe_objects  AS obj
    INNER JOIN sys.dm_xe_packages AS pkg  ON pkg.guid = obj.package_guid
WHERE obj.object_type in ('action',  'event',  'target')
ORDER BY obj.object_type,
    pkg.name,
    obj.name;

Erstellen einer Sitzung für erweiterte Ereignisse

Nachstehend sehen Sie den grundlegenden Prozess zur Erstellung einer Sitzung für erweiterte Ereignisse mithilfe des Dialogfelds Neue Sitzung in SQL Server Management Studio. Sie gelangen zu diesem Bildschirm, indem Sie in SSMS erst den Knoten Verwaltung und dann den Knoten „Erweiterte Ereignisse“ aufklappen, mit der rechten Maustaste auf „Sitzungen“ klicken und Neue Sitzung auswählen.

Die obige Abbildung zeigt das Dialogfeld Neue Sitzung für das Feature „Erweiterte Ereignisse“. Sie müssen die Sitzung zunächst benennen. SQL Server stellt zahlreiche Vorlagen zur Verfügung, die in die folgenden Kategorien gruppiert sind:

• Sperren und Blockierungen
• Profiler-Entsprechungen
• Abfrageausführung
• Systemüberwachung

Mit diesen vordefinierten Vorlagen können Sie schnell mit der Verwendung erweiterter Ereignisse für die Überwachung beginnen. In diesem Beispiel werden der Sitzung manuell Ereignisse hinzugefügt, um Sie durch alle Optionen zu führen. Für den Einstieg kann eine Vorlage jedoch eine unkomplizierte Möglichkeit zum Erstellen einer einfachen Sitzung sein.

Sie verfügen über eine Reihe von Optionen mit Kontrollkästchen für den Start dieser Sitzung. Sie können wählen, ob Ihre neue Sitzung beim Start des Servers gestartet werden soll, oder ob die Sitzung sofort nach ihrer Erstellung beginnen soll. Administratoren können Sitzungen für erweiterte Ereignisse jederzeit über den Knoten Erweiterte Ereignisse in SQL Server Management Studio starten und beenden. Sie haben auch die Möglichkeit, die Kausalitätsverfolgung zu aktivieren, die der Ausgabe jedes Ereignisses einen eindeutigen Bezeichner (GUID) und eine Sequenznummer hinzufügt, wodurch Sie die Reihenfolge, in der die Ereignisse aufgetreten sind, leicht nachvollziehen können.

In der obigen Abbildung wird der Bildschirm angezeigt, auf dem Sie die Ereignisse zu Ihrer Sitzung hinzufügen. Ein Ereignis stellt einen Point of Interest innerhalb des Codes der Datenbank-Engine. Diese können rein interne Systemvorgänge darstellen, oder sie können Benutzeraktionen wie der Ausführung von Abfragen zugeordnet sein. Im obigen Beispiel können Sie sehen, dass dieser Ereignissitzung die Ereignisse sp_statement_completed, sql_batch_completed und sql_statement_completed hinzugefügt wurden. Standardmäßig würde diese Sitzung alle Instanzen dieser Ereignisse erfassen, die in Ihrer Instanz stattfinden. Sie können die Erfassung einschränken, indem Sie auf die Schaltfläche „Konfigurieren“ klicken.

Der Bildschirm „Ereigniskonfiguration“ ermöglicht das Definieren der Daten, die Sie in Bezug auf Ihre Ereignisse sammeln. Globale Felder ermöglichen Ihnen die Auswahl der Daten, die Sie sammeln, wenn Ihr Ereignis eintritt. Globale Felder werden auch als Aktionen bezeichnet, da die Aktion darin besteht, dem Ereignis zusätzliche Datenfelder hinzuzufügen. Diese Felder stellen die Daten dar, die beim Auftreten des erweiterten Ereignisses erfasst werden, und sind für die meisten erweiterten Ereignisse gleich. Die folgende Abbildung zeigt die Filteroptionen für ein erweitertes Ereignis.

Filter sind eine leistungsstarke Funktion von erweiterten Ereignissen, mit der Sie eine präzise Steuerung verwenden können, um nur die spezifischen Vorkommen des Ereignisses zu erfassen, die Sie auch erfassen möchten. In diesem Beispiel können Sie sehen, dass der Filter auf das Feld sqlserver.is_system angewendet wird, wenn es gleich Null ist, was darauf hinweist, dass die Abfrage kein interner Vorgang ist. Das heißt, die Sitzung erfasst nicht die Ausführung von Anweisungen, die von Systemverbindungen übermittelt werden, und wir möchten nur Anweisungen erfassen, die von Benutzern oder Benutzeranwendungen übermittelt werden.

Filter gelten für ein einzelnes Feld eines einzelnen Ereignisses. Wenn Sie sicherstellen möchten, dass Sie keine Systemaktivitäten für Ereignisse nachverfolgen, benötigen Sie für jedes Ereignis einen eigenen Filter, und zwar für die Ereignisse sql_statement_completed, sql_batch_completed und sp_statement_completed.

Es empfiehlt sich, einen Filter für jedes Ereignis zu konfigurieren, das Sie erfassen. Auf diese Weise können Sie die Effizienz der Datenerfassung verbessern und den Schwerpunkt Ihrer Suche eingrenzen.

Die Abbildung unten zeigt die Ereignisfelder, die gesammelt werden. Diese sind spezifisch für das ausgelöste Ereignis und können optionale Felder für die Sammlung enthalten. Im obigen Ereignis können Sie sehen, dass statement und parameterized_plan_handle die optionalen Sammlungsoptionen sind.

Nachdem Sie eine Ereignissitzung definiert haben, legen Sie ein Speicherziel fest, wie in der folgenden Abbildung dargestellt.

Eine erweiterte Ereignissitzung hat ein Ziel – Ein Ziel können Sie sich einfach als einen Ort vorstellen, an dem die Engine die Vorkommen eines Ereignisses nachverfolgt. Zwei der gängigsten Ziele sind Ereignisdateien, also Dateien im Dateisystem, in denen Ereignisse gespeichert werden können. In Azure SQL PaaS-Angeboten werden diese Daten in einen Blobspeicher geschrieben. Ein weiteres gängiges Ziel ist der Ringpuffer, der sich im Speicher der SQL Server-Instanz befindet. Der Ringpuffer wird am häufigsten für die Livebeobachtung einer Ereignissitzung verwendet, da es sich um einen zirkulären Speicher handelt und die Daten nicht über eine Sitzung hinaus beibehalten werden. Die meisten Ziele verarbeiten Daten asynchron, was bedeutet, dass die Ereignisdaten in den Speicher geschrieben werden, bevor sie auf dem Datenträger beibehalten werden. Eine Ausnahme bilden die Ziele „Ereignisablaufverfolgung für Windows“ (ETW) und „Ereigniszähler“, die synchron verarbeitet werden.

Die folgende Tabelle enthält Informationen und Verwendungszwecke für jeden Zieltyp für erweiterte Ereignisse.

Target	Beschreibung	Verarbeitung
Ereigniszähler	Zählt alle Ereignisse, die während einer Sitzung für erweiterte Ereignisse aufgetreten sind. Hiermit werden Informationen zu Workloadmerkmalen für eine Workload ohne den Aufwand einer vollständigen Ereignissammlung abgerufen.	Synchron
Ereignisdatei	Schreibt die Ausgabe der Ereignissitzung aus dem Arbeitsspeicher in eine persistente Datei auf dem Datenträger.	Asynchron
Ereignispaarbildung	Viele Ereignisse, die in der Regel paarweise auftreten (z. B. Sperre erfassen, Sperre freigeben), und diese Sammlung können verwendet werden, um zu identifizieren, wenn diese Ereignisse nicht in einem übereinstimmenden Satz auftreten.	Asynchron
Ereignisablaufverfolgung für Windows (ETW)	Wird verwendet, um SQL Server-Ereignisse mit den Ereignisdaten des Windows-Betriebssystems zu korrelieren.	Synchron
Histogramm	Dies ähnelt dem Ereigniszähler, bei dem die Vorkommen eines Ereignisses gezählt werden. Der Unterschied besteht darin, dass das Histogramm basierend auf einer bestimmten Ereignisspalte oder Aktion zählen kann.	Asynchron
Ringpuffer	Wird zum Speichern von Daten im Arbeitsspeicher verwendet. Daten werden nicht persistent auf dem Datenträger gespeichert und möglicherweise häufig aus dem Puffer gelöscht.	Asynchron

Alternativ können Sie mit T-SQL eine Sitzung für erweiterte Ereignisse erstellen. Die folgenden T-SQL-Befehle enthalten ein Beispiel zum Erstellen einer Sitzung für erweiterte Ereignisse:

IF EXISTS (SELECT * FROM sys.server_event_sessions WHERE name='test_session')
    DROP EVENT session test_session ON SERVER;
GO

CREATE EVENT SESSION test_session
ON SERVER
    ADD EVENT sqlos.async_io_requested,
    ADD EVENT sqlserver.lock_acquired
    ADD TARGET package0.etw_classic_sync_target (SET default_etw_session_logfile_path = N'C:\demo\traces\sqletw.etl' )
    WITH (MAX_MEMORY=4MB, MAX_EVENT_SIZE=4MB);
GO

Ereignissitzungen können auf den Server- oder Datenbankbereich festgelegt werden. Im oben gezeigten Beispiel fügen Sie zwei Ereignisse hinzu und verwenden den ETW-Pfad (Ereignisablaufverfolgung für Windows) mit einem Dateispeicherort. Nachdem Sie die Sitzung erstellt haben, müssen Sie sie starten. Dies kann über T-SQL erfolgen. Mit ALTER und STATE können Sie die Sitzung ändern, oder Sie können SQL Server Management Studio dafür verwenden.