Teilen über

Erweiterte Ereignisse in Azure SQL-Datenbank und Azure SQL Managed Instance

  • Artikel

Gilt für: Azure SQL-Datenbank Azure SQL Managed Instance

Eine Einführung in erweiterte Ereignisse finden Sie unter:

Die Featuresätze, Funktionen und Verwendungsszenarien für erweiterte Ereignisse in Azure SQL-Datenbank und Azure SQL Managed Instance ähneln den verfügbaren Funktionen in SQL Server. Die Hauptunterschiede sind:

  • Das Ziel event_file verwendet immer Blobs in Azure Storage und nicht Dateien auf dem Datenträger.
  • Azure SQL-Datenbank Ereignissitzungen sind immer auf Datenbankebene. Das bedeutet Folgendes:
    • Eine Ereignissitzung in einer Datenbank kann keine Daten oder Ereignisse in einer anderen Datenbank sammeln.
    • Ein Ereignis muss im Kontext einer Benutzerdatenbank auftreten, die in eine Sitzung aufgenommen werden soll.
  • In Azure SQL Managed Instance können Sie sowohl Ereignissitzungen sowohl auf Server- als auch auf Datenbankebene erstellen. Es wird empfohlen, Ereignissitzungen auf Serverebene für die meisten Szenarien zu verwenden.

Erste Schritte

Es gibt zwei Beispiele, die Ihnen schnell bei den ersten Schritten mit erweiterten Ereignissen in Azure SQL-Datenbank und Azure SQL Managed Instance helfen:

  • Erstellen Sie eine Sitzung mit einem event_file-Ziel in Azure Storage. In diesem Beispiel wird gezeigt, wie Ereignisdaten in einer Datei (BLOB) in Azure Storage mithilfe des Ziels event_file erfasst werden. Verwenden Sie diese Vorgehensweise, wenn Sie erfasste Ereignisdaten beibehalten müssen oder wenn Sie die Ereignisanzeige in SQL Server Management Studio (SSMS) zum Analysieren erfasster Daten verwenden möchten.
  • Erstellen Sie eine Sitzung mit einem ring_buffer-Ziel im Arbeitsspeicher. In diesem Beispiel wird gezeigt, wie Sie die neuesten Ereignisse aus einer Ereignissitzung im Arbeitsspeicher mithilfe des Ziels ring_buffer erfassen. Verwenden Sie dies als schnelle Möglichkeit, um aktuelle Ereignisse während Ad-hoc-Untersuchungen oder Problembehandlungen anzuzeigen, ohne erfasste Ereignisdaten speichern zu müssen.

Erweiterte Ereignisse können verwendet werden, um schreibgeschützte Replikate zu überwachen. Weitere Informationen finden Sie unter Lesen von Abfragen auf Replikaten.

Bewährte Methoden

Übernehmen Sie die folgenden bewährten Methoden, um erweiterte Ereignisse in Azure SQL-Datenbank und Azure SQL Managed Instance zuverlässig und ohne Auswirkungen auf die Leistung vom Datenbank-Engine und Arbeitsauslastung zu verwenden.

  • Wenn Sie das Ziel event_file verwenden:
    • Verwenden Sie ein Speicherkonto in derselben Azure-Region wie die Datenbank bzw. die verwaltete Instanz, in der Sie Ereignissitzungen erstellen.
    • Richten Sie die Redundanz des Speicherkontos an der Redundanz der Datenbank, des elastischen Pools oder der verwalteten Instanz aus. Verwenden Sie für lokal redundante Ressourcen LRS, GRS oder RA-GRS. Verwenden Sie für zonenredundante Ressourcen ZRS, GZRS oder RA-GZRS. Weitere Informationen finden Sie unter Azure Storage-Redundanz.
    • Verwenden Sie keine andere Blob-Zugriffsebene als Hot.
  • Wenn Sie eine fortlaufend ausgeführte Ereignissitzung erstellen möchten, die nach jedem Datenbank-Engine-Neustart automatisch gestartet wird (z. B. nach einem Failover oder einem Wartungsereignis), schließen Sie die Ereignissitzungsoption STARTUP_STATE = ON in Ihre CREATE EVENT SESSION- oder ALTER EVENT SESSION-Anweisungen ein.
  • Verwenden Sie STARTUP_STATE = OFF dagegen für kurzfristige Ereignissitzungen, wie z. B. bei ad-hoc-Problembehandlungen.
  • Lesen Sie in Azure SQL-Datenbank keine Deadlock-Ereignisse aus der integrierten dl-Ereignissitzung. Wenn sich eine große Anzahl von Deadlock-Ereignissen angesammelt hat, kann das Lesen mit der Funktion sys.fn_xe_file_target_read_file() zu einem Fehler durch unzureichenden Arbeitsspeicher in der master-Datenbank führen. Dies kann sich auf die Anmeldungsverarbeitung auswirken und zu einem Anwendungsausfall führen. Die empfohlenen Möglichkeiten zum Überwachen von Deadlocks finden Sie unter Erfassen von Deadlockdiagrammen in Azure SQL-Datenbank mit erweiterten Ereignissen.

Ereignissitzungsziele

Die folgenden Ziele werden von Azure SQL-Datenbank und Azure SQL Managed Instance unterstützt:

  • event_file-Ziel. Schreibt vollständige Puffer in einen Blob in einen Azure Storage-Container.
  • ring_buffer-Ziel. Enthält Ereignisdaten im Arbeitsspeicher, bis sie durch neue Ereignisdaten ersetzt werden.
  • event_counter-Ziel. Zählt alle Ereignisse, die während einer Sitzung für erweiterte Ereignisse auftreten.
  • Histogramm-Ziel. Zählt die Vorkommen verschiedener Werte von Feldern oder Aktionen in separaten Buckets.
  • event_stream. Streamt Ereignisdaten in eine .NET-Anwendung.

Hinweis

Das event_stream Ziel in Azure SQL-Datenbank und Azure SQL Managed Instance befindet sich in der Vorschau.

Transact-SQL-Unterschiede

Wenn Sie die EREIGNISSITZUNG ERSTELLEN, EREIGNISSITZUNG ÄNDERN und EREIGNISSITZUNG WEGLASSEN Anweisungen in SQL Server und in Azure SQL Managed Instance ausführen, verwenden Sie die ON SERVER Klausel. In Azure SQL-Datenbank verwenden Sie stattdessen die ON DATABASE-Klausel, da in Azure SQL-Datenbank Ereignissitzungen datenbankbezogen sind.

Katalogsichten für erweiterte Ereignisse

Erweiterte Ereignisse bieten mehrere Katalogansichten. Katalogansichten informieren Sie über die Metadaten oder Definition von Ereignissitzungen. Diese Ansichten geben keine Informationen zu Instanzen aktiver Ereignissitzungen zurück.

Name der Katalogansicht BESCHREIBUNG
sys.database_event_session_actions Gibt für jede Aktion jedes Ereignisses einer Ereignissitzung eine Zeile zurück.
sys.database_event_session_events Gibt eine Zeile für jedes Ereignis in einer Ereignissitzung zurück.
sys.database_event_session_fields Gibt eine Zeile für jede anpassbare Spalte zurück, die für Ereignisse und Ziele explizit festgelegt wurde.
sys.database_event_session_targets Gibt für eine Ereignissitzung eine Zeile für jedes Ereignisziel zurück.
sys.database_event_sessions Gibt eine Zeile für jede Ereignissitzung in der Datenbank zurück.

Dynamische Verwaltungssichten für erweiterte Ereignisse

Erweiterte Ereignisse bietet verschiedene dynamische Verwaltungsansichten (DMVs). DMVs geben Informationen zu gestarteten Ereignissitzungen zurück.

DMV-Name BESCHREIBUNG
sys.dm_xe_database_session_event_actions Gibt Informationen zu Ereignissitzungsaktionen zurück.
sys.dm_xe_database_session_events Gibt Informationen zu Sitzungsereignissen zurück.
sys.dm_xe_database_session_object_columns Zeigt die Konfigurationswerte für Objekte an, die an eine Sitzung gebunden sind.
sys.dm_xe_database_session_targets Gibt Informationen zu Sitzungszielen zurück.
sys.dm_xe_database_sessions Gibt eine Zeile für jede laufende Ereignissitzung in der aktuellen Datenbank zurück.

Allgemeine DMVs

Es gibt zusätzliche DMVs (dynamische Verwaltungssichten) für Erweiterte Ereignisse, die Azure SQL-Datenbank, Azure SQL Managed Instance und SQL Server gemeinsam haben:

Verfügbare erweiterten Ereignisse, Aktionen und Ziele

Genau wie in SQL Server können Sie mithilfe dieser Abfrage verfügbare Ereignisse, Aktionen und Ziele abrufen:

SELECT o.object_type,
       p.name AS package_name,
       o.name AS db_object_name,
       o.description AS db_obj_description
FROM sys.dm_xe_objects AS o
INNER JOIN sys.dm_xe_packages AS p
ON p.guid = o.package_guid
WHERE o.object_type IN ('action','event','target')
ORDER BY o.object_type,
         p.name,
         o.name;

Berechtigungen

Tipp

Im Jahr 2022 hat Microsoft eine Reihe neuer differenzierterer Berechtigungen für erweiterte Ereignisse eingeführt, weitere Informationen finden Sie im Blog: Neue granulare Berechtigungen für SQL Server 2022 und Azure SQL, um die Einhaltung von PoLP zu verbessern.

In Azure SQL-Datenbank und Azure SQL Managed Instance unterstützen erweiterte Ereignisse ein präzises Berechtigungsmodell. Es können folgende Berechtigungen erteilt werden:

CREATE ANY DATABASE EVENT SESSION
DROP ANY DATABASE EVENT SESSION
ALTER ANY DATABASE EVENT SESSION
ALTER ANY DATABASE EVENT SESSION ADD EVENT
ALTER ANY DATABASE EVENT SESSION DROP EVENT
ALTER ANY DATABASE EVENT SESSION ADD TARGET
ALTER ANY DATABASE EVENT SESSION DROP TARGET
ALTER ANY DATABASE EVENT SESSION ENABLE
ALTER ANY DATABASE EVENT SESSION DISABLE
ALTER ANY DATABASE EVENT SESSION OPTION

Informationen dazu, was jedes dieser Berechtigungssteuerelemente enthält, finden Sie unter CREATE EVENT SESSION, ALTER EVENT SESSION und DROP EVENT SESSION.

Alle diese Berechtigungen sind in der Berechtigung in der Datenbank oder der verwalteten Instanz CONTROL enthalten. Der Datenbankbesitzer (dbo), Mitglieder der db_owner-Datenbankrolle und der Administrator des logischen Servers enthalten die für Datenbank-CONTROL-Berechtigung. In Azure SQL Managed Instance enthalten Mitglieder der sysadmin Serverrolle die CONTROL Berechtigung für die Instanz.

Speichercontainerautorisierung und -steuerung

Wenn Sie das event_file-Ziel verwenden, werden Ereignisdaten in Blobs in einem Azure Storage-Container gespeichert. Die Datenbank-Engine, die die Ereignissitzung ausführt, muss über einen bestimmten Zugriff auf diesen Container verfügen. Sie können diesen Zugriff auf eine der folgenden Arten gewähren:

  • Weisen Sie die RBAC-Rolle "Storage Blob Data Contributor" der verwalteten Identität des logischen Azure SQL-Servers oder der azure SQL-verwalteten Instanz im Container zu, und erstellen Sie eine Anmeldeinformation, um die Datenbank-Engine anzuweisen, verwaltete Identität für die Authentifizierung zu verwenden.

    Alternativ zum Zuweisen der RBAC-Rolle " Storage Blob Data Contributor " können Sie die folgenden RBAC-Aktionen zuweisen:

    Namespace Aktion
    Microsoft.Storage/storageAccounts/blobServices/containers/ read
    Microsoft.Storage/storageAccounts/blobServices/containers/blobs/ delete
    Microsoft.Storage/storageAccounts/blobServices/containers/blobs/ read
    Microsoft.Storage/storageAccounts/blobServices/containers/blobs/ write

    Hinweis

    Die Verwendung von verwalteter Identität mit erweiterten Ereignissitzungen befindet sich in der Vorschau.

  • Erstellen Sie ein SAS-Token für den Container, und speichern Sie das Token in einer Anmeldeinformation.

    In Azure SQL-Datenbank müssen Sie Anmeldeinformationen mit Datenbankbereich verwenden. Verwenden Sie in Azure SQL Managed Instance eine serverbezogene Anmeldeinformation.

    Das SAS-Token, das Sie für Ihren Azure Storage-Container erstellen, muss die folgenden Anforderungen erfüllen:

    • Besitzen Sie die rwdl (Read, Write, Delete, List) Berechtigungen.
    • die Startzeit und die Ablaufzeit haben, die die Lebensdauer der Ereignissitzung umfasst.
    • Keine Einschränkungen für IP-Adressen haben.

Ressourcengovernance

In Azure SQL-Datenbank wird der Speicherverbrauch durch erweiterte Ereignissitzungen dynamisch durch die Datenbank-Engine gesteuert, um den Ressourcenkonflikt zu minimieren.

Für Ereignissitzungen gibt es eine Beschränkung des verfügbaren Arbeitsspeichers:

  • In einer einzelnen Datenbank ist der gesamte Sitzungsspeicher auf 128 MB begrenzt.
  • In einem Pool für elastische Datenbanken sind die einzelnen Datenbanken durch die Grenzwerte für einzelne Datenbanken begrenzt und dürfen insgesamt 512 MB nicht überschreiten.

Wenn Sie eine Fehlermeldung erhalten, die auf einen Speichergrenzwert verweist, sind die Korrekturmaßnahmen, die Sie ausführen können:

  • Führen Sie weniger gleichzeitige Ereignissitzungen durch.
  • Verwenden von CREATE- und ALTER-Anweisungen für Ereignissitzungen, verringern der Menge an Arbeitsspeicher, die Sie in der MAX_MEMORY-Klausel für die Sitzung angeben.

Hinweis

In erweiterten Ereignissen wird die MAX_MEMORY-Klausel in zwei Kontexten angezeigt: beim Erstellen oder Ändern einer Sitzung (auf Sitzungsebene) und bei Verwendung des ring_buffer-Ziels (auf Zielebene). Die oben genannten Grenzwerte gelten für den Arbeitsspeicher auf Sitzungsebene.

Für die Anzahl der gestarteten Ereignissitzungen in Azure SQL-Datenbank gilt ein Grenzwert:

  • In einer einzelnen Datenbank beträgt der Grenzwert 100.
  • In einem Pool für elastische Datenbanken beträgt der Grenzwert 100 datenbankbezogene Sitzungen pro Pool.

In umfangreichen Pools für elastische Datenbanken kann das Starten einer neuen erweiterten Ereignissitzung aufgrund von Speichereinschränkungen fehlschlagen, auch wenn die Gesamtzahl der gestarteten Sitzungen unter 100 liegt.

Um den gesamt von einer Ereignissitzung verbrauchten Arbeitsspeicher zu ermitteln, führen Sie die folgende Abfrage aus, während eine Verbindung mit der Datenbank besteht, in der die Ereignissitzung gestartet wird:

SELECT name AS session_name,
       total_buffer_size + total_target_memory AS total_session_memory
FROM sys.dm_xe_database_sessions;

Um den gesamten Ereignissitzungsspeicher für einen elastischen Pool zu finden, muss diese Abfrage in jeder Datenbank im Pool ausgeführt werden.

Zugehöriger Inhalt