Freigeben über

Erweiterte Ereignisse in Azure SQL

Gilt für:Azure SQL-DatenbankAzure SQL Managed InstanceSQL-Datenbank in Fabric

Eine Einführung in erweiterte Ereignisse finden Sie unter:

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

  • In Der Azure SQL-Datenbank, der SQL-Datenbank in Fabric und der von Azure SQL verwalteten Instanz verwendet das event_file Ziel immer Blobs in Azure Storage und nicht Dateien auf dem Datenträger.
    • In SQL Server kann das event_file Ziel entweder Dateien auf datenträgern oder BLOBs in Azure Storage verwenden.
  • In Azure SQL-Datenbank und SQL-Datenbank in Fabric werden Ereignissitzungen immer datenbankbereichsbezogenen. 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.

Get started

Es gibt zwei exemplarische Vorgehensweisen, mit denen Sie schnell mit erweiterten Ereignissen beginnen können:

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 sicher, zuverlässig und ohne Auswirkungen auf die Leistung des Datenbankmoduls und der Arbeitsauslastung zu verwenden.

  • Wenn Sie das Ziel event_file verwenden:
    • Je nach den Ereignissen, die einer Sitzung hinzugefügt wurden, können die vom event_file Ziel erstellten Dateien vertrauliche Daten enthalten. Überprüfen Sie sorgfältig RBAC-Rollenzuweisungen und die Zugriffssteuerungslisten (Access Control Lists, ACL) für das Speicherkonto und den Container, einschließlich geerbter Zugriff, um unnötige Lesezugriffe zu vermeiden. Folgen Sie dem Prinzip der geringsten Rechte.
    • 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.
    • Aktivieren Sie den hierarchischen Namespace für das Speicherkonto nicht.
  • 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 Anmeldeverarbeitung 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

Weitere Informationen zu erweiterten Ereigniszielen, die in azure SQL-Datenbank, SQL-Datenbank in Fabric, von Azure SQL verwaltete Instanz und SQL Server unterstützt werden, finden Sie unter "Ziele für erweiterte Ereignisse".

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.

Eine Liste der Katalogansichten für jede Plattform finden Sie unter "Erweiterte Ereigniskatalogansichten".

Dynamische Verwaltungssichten für erweiterte Ereignisse

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

Eine Liste der DMVs für jede Plattform finden Sie unter Dynamische Verwaltungsansichten für erweiterte Ereignisse.

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

Mit dieser Abfrage können Sie 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;

Permissions

Detaillierte Berechtigungen nach Plattform finden Sie unter "Berechtigungen ".

Speichercontainerautorisierung und -steuerung

Wenn Sie das event_file Ziel mit Azure Storage-Blobs verwenden, muss das Datenbankmodul, das die Ereignissitzung ausführt, über einen bestimmten Zugriff auf den BLOB-Container verfügen. Sie können diesen Zugriff auf eine der folgenden Arten gewähren:

  • Weisen Sie der verwalteten Identität des logischen Azure SQL-Servers oder der verwalteten Azure SQL-Instanz die RBAC-Rolle Mitwirkender an Storage-Blobdaten für den Container zu, und erstellen Sie Anmeldeinformationen, um das Datenbankmodul anzuweisen, sich mithilfe der verwalteten Identität zu authentifizieren.

    Alternativ zum Zuweisen der RBAC-Rolle Mitwirkender an Storage-Blobdaten können Sie die folgenden RBAC-Aktionen zuweisen:

    Namespace Action
    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

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

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

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

    • Sie müssen über die Berechtigungen rwdl (Read, Write, Delete, 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.

Note

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.

Verwandte Inhalte