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

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

Eine Einführung in erweiterte Ereignisse finden Sie unter:

• Erweiterte Ereignisse
• Schnellstart: Erweiterte Ereignisse

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:
  • Legen Sie die EVENT_RETENTION_MODE-Option nicht auf NO_EVENT_LOSS fest. Dies kann neben anderen Problemen, die sich auf die Verfügbarkeit der Datenbank bzw. der verwalteten Instanz auswirken, zu Verbindungstimeouts und Failoververzögerungen führen.
  • 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.

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.

Dynamische Verwaltungssichten für erweiterte Ereignisse

Erweiterte Ereignisse bietet verschiedene dynamische Verwaltungsansichten (DMVs). DMVs geben Informationen zu gestarteten Ereignissitzungen 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:

• sys.dm_xe_map_values
• sys.dm_xe_object_columns
• sys.dm_xe_objects
• sys.dm_xe_packages

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

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

CREATE ANY EVENT SESSION
DROP ANY EVENT SESSION
ALTER ANY EVENT SESSION
ALTER ANY EVENT SESSION ADD EVENT
ALTER ANY EVENT SESSION DROP EVENT
ALTER ANY EVENT SESSION ADD TARGET
ALTER ANY EVENT SESSION DROP TARGET
ALTER ANY EVENT SESSION ENABLE
ALTER ANY EVENT SESSION DISABLE
ALTER ANY 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 gewähren diesen Zugriff, indem Sie ein SAS-Token für den Container erstellen und das Token in datenbankbezogenen Anmeldeinformationen speichern.

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:

• Über die Berechtigungen rwl (Read, Write, List) verfügen.
• 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.

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

• Erweiterte Ereignisse
• Schnellstart: Erweiterte Ereignisse