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:

• Erweiterte Ereignisse
• Schnellstart: Erweiterte Ereignisse

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 sind Ereignissitzungen immer auf Datenbankebene festgelegt. Das bedeutet Folgendes:
  • Eine Ereignissitzung in einer Datenbank kann keine Ereignisse aus einer anderen Datenbank erfassen.
  • 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 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:

• Erstellen Sie eine Ereignissitzung mit einem Ziel vom Typ event_file in Azure Storage. In diesem Beispiel wird gezeigt, wie Sie Ereignisdaten in einer Datei (Blob) in Azure Storage mithilfe des event_file Ziels erfassen und Anleitungen zur Problembehandlung für häufige Fehler enthalten. 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 Ereignissitzung mit einem Ringpuffer-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.

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

Bewährte Methoden

Befolgen Sie die folgenden bewährten Methoden, um Extended Events sicher und zuverlässig zu verwenden, ohne die Integrität der Datenbank-Engine und die Leistung der Workloads zu beeinträchtigen.

• 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.

Ziele der Ereignissitzung

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.

Katalogansichten für erweiterte Ereignisse

Erweiterte Ereignisse bieten mehrere Katalogansichten. Katalogansichten geben Auskunft ü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 Extended Events

Extended Events bieten verschiedene dynamische Verwaltungsansichten (DMVs). DMVs geben Informationen über gestartete 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:

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

Verfügbare 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.

  Als Alternative zur Zuweisung der RBAC-Rolle Mitwirkender für 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 datenbankbezogene Anmeldeinformationen 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.
  • Legen Sie die Start- und Endzeit so fest, dass sie die gesamte Dauer der Ereignis-Sitzung abdecken.
  • Keine Einschränkungen für IP-Adressen haben.

Netzwerksicherheitsperimeter (Vorschau)

Network Security Perimeter (Vorschau) legt eine Netzwerkzugangsgrenze um Azure SQL-Datenbank und andere Azure-Plattformen als Dienstleistung (PaaS)-Ressourcen herum. Wenn Sie einen logischen Server mit einem Network Security Perimeter (NSP) verknüpfen, unterliegen die ausgehenden Verbindungen, die Extended Events zu Azure Storage herstellen, den Zugriffsregeln des Perimeters.

Wie Extended Events Netzwerkzugang nutzt

Extended Events stellt ausgehende Verbindungen von der Datenbank-Engine zu Azure Storage in zwei Fällen her:

• Ereignisdaten schreiben. Wenn Sie eine Ereignissitzung mit einem event_file Ziel starten, das auf einen Blob zeigt, überprüft die Datenbank-Engine den ausgehenden Zugriff vor Beginn der Sitzung und spült jedes Mal erneut Eventpuffer zum Blob.
• Lese Ereignisdaten aus. Wenn du sys.fn_xe_file_target_read_file oder sys.fn_MSxe_read_event_stream mit einer Blob-URL aufrufst, prüft das Datenbank-Engine den ausgehenden Zugriff, wenn die Funktion initialisiert wird. SSMS ruft sys.fn_MSxe_read_event_stream auf, wenn Sie erfasste Ereignisdaten in der Ereignisanzeige öffnen.

Eingehende TDS-Verbindungen, die zur Verwaltung von Ereignissitzungen über T-SQL verwendet werden, benötigen keine für Extended Events spezifische NSP-Konfiguration. Die Anweisungen CREATE EVENT SESSION, ALTER EVENT SESSION und DROP EVENT SESSION sowie die Lesefunktionen werden alle über eine normale Clientverbindung ausgeführt, sodass sie denselben Zugriffsregeln für eingehende Verbindungen folgen wie jede andere Clientverbindung zur Datenbank.

Unterstützte Konfigurationen

Das Verhalten hängt vom Zugriffsmodus des Perimeters ab, davon, ob sich das Speicherkonto im selben Bereich wie der logische Server befindet und ob zwei verschiedene Perimeter miteinander verknüpft sind.

Konfigurieren Sie den ausgehenden Zugriff auf das Speicherkonto

Wenn Sie eine Datenbank für erweiterte Ereignisse konfigurieren, können Sie zwischen verwalteter Identität und SAS-Token-Authentifizierung wählen. Der von Ihnen gewählte Authentifizierungsmechanismus bestimmt, ob Sie eine Outbound-Zugriffsregel benötigen.

1. Überprüfen Sie die Perimeter-Verbindung. Im Azure-Portal suchen Sie nach Network Security Perimeter, wählen Sie Ihren Perimeter aus und wählen Sie dann im Menü Einstellungen "Associated Resources", um zu bestätigen, dass Ihr Server gelistet ist. Weitere Informationen finden Sie unter Netzwerksicherheitsperimeter.
2. Wählen Sie Ihren Authentifizierungsmechanismus. Verwenden Sie eine Authentifizierung mit verwalteter Identität. Ein Managed Identity Token enthält die Ansprüche, die der Perimeter benötigt, sodass du keine Outbound-Regel hinzufügen musst und den nächsten Schritt überspringen kannst.
3. Fügen Sie eine Outbound-Zugriffsregel hinzu (nur SAS-Token). Wenn du ein SAS-Token verwendest und der Perimeter im Enforced-Modus ist, füge eine Outbound-Zugriffsregel im Perimeter-Profil hinzu. Verwenden Sie zum Beispiel myxedata.blob.core.windows.netden Regeltyp Vollständig qualifizierte Domainnamen (FQDN) und den Hostnamen Ihres Speicherkontos als Wert.

In diesem Beispiel kannst du mit *.blob.core.windows.net jedes Azure Storage-Konto zulassen, aber diese Einstellung erlaubt ausgehende Verbindungen mit Speicherkonten, die dir nicht gehören. Benutze den spezifischen Host-Namen, wo immer du kannst.

Halte den Perimeter im Übergangsmodus, bis du bestätigt hast, welche Outbound-Regeln du brauchst. Im Übergangsmodus protokolliert der Perimeter die Regelbewertungen, ohne den Zugriff zu blockieren, sodass du fehlende Regeln finden kannst, bevor sie Fehler verursachen. Wechsel in den erzwungenen Modus, nachdem die Regeln eingeführt sind.

Einschränkungen und Verhaltensunterschiede

• Die Datenbank-Engine prüft den ausgehenden Zugriff, wenn eine Sitzung startet und bei jedem Pufferflush. Wenn du eine Outbound-Regel entfernst, während eine Sitzung läuft, hört die Sitzung nicht auf. Einzelne Puffer-Schreibvorgänge beginnen stattdessen fehlzuschlagen.
• Verwaltete Identitäten und SAS-Token sind unter einem Perimeter nicht gleichwertig. Ein Token für eine verwaltete Identität enthält Perimeteransprüche, daher benötigt es keine ausgehende Regel. Ein SAS-Token enthält diese Claims nicht, daher ist im erzwungenen Modus eine passende ausgehende Regel erforderlich.
• Eine blockierte Lesefunktion führt möglicherweise keinen Fehler aus. Wenn ein Perimeter sys.fn_MSxe_read_event_stream oder sys.fn_xe_file_target_read_file blockiert, kann die Funktion den Fehler 25759 oder 25717 auslösen oder eine leere Ergebnismenge ohne Fehlermeldung zurückgeben. Wenn du Daten erwartest, aber keine Zeilen und keine Fehler bekommst, überprüfe deine Outbound-Regeln.

Fehler, wenn ein Perimeter den Zugang blockiert

Fehler 25602 bedeutet, dass das event_file Ziel nicht initialisieren konnte, weil der Perimeter die ausgehende Verbindung zum Speicherkonto blockiert hat:

The target, "<target_name>", encountered a configuration error during initialization. Object cannot be added to the event session.
For more information, see https://go.microsoft.com/fwlink/?linkid=2336061.

Fehler 25759 bedeutet, dass ein Perimeter eine Lesefunktion blockiert hat:

Network Security Perimeter (NSP) blocked outbound access to the storage URL '<url>'.
The NSP configuration does not allow reading from the specified location.

Fehler 25717 bedeutet, dass der Zugriff entzogen wurde, während eine Lesefunktion einen Lesevorgang ausführte. Da die Datenbank-Engine BLOB-Daten blockweise liest, anstatt ganze Dateien herunterzuladen, kann dieser Fehler mitten in einer Ergebnismenge auftreten:

The operating system returned error <error details> while reading from the file '<url>'.

Um einen dieser Fehler zu beheben, wechseln Sie zur Managed Identity Authentication, fügen Sie eine Outbound-FQDN-Regel hinzu, die mit dem Hostnamen des Speicherkontos übereinstimmt, oder verschieben Sie das Speicherkonto an denselben Umfang wie der logische Server.

Für weitere diagnostische Details zu Zielinitialisierungen und Pufferschreibfehlern suchen Sie im Extended Events-Engine-Log:

SELECT CONVERT(xml, record) AS record_xml
FROM sys.dm_os_ring_buffers
WHERE ring_buffer_type = 'RING_BUFFER_XE_LOG';

Änderungen der Perimeter-Assoziationen und Änderungen des Zugriffsmodus erscheinen im Azure-Aktivitätsprotokoll für den logischen Server. Eingehende und ausgehende Regelauswertungen erscheinen in den Netzwerksicherheitsperimeter-Diagnoseprotokollen.

Ressourcenverwaltung

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

Der für Ereignissitzungen verfügbare Arbeitsspeicher ist begrenzt:

• 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 Sie CREATE- und ALTER-Anweisungen für Ereignissitzungen, um die Menge an Arbeitsspeicher zu verringern, 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 elastischen Pool liegt das Limit bei 100 datenbankbezogenen 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

• Erweiterte Ereignisse
• Schnellstart: Erweiterte Ereignisse
• Netzwerksicherheitsperimeter für Azure SQL-Datenbank (Vorschau)