Uitgebreide gebeurtenissen in Azure SQL

van toepassing op:Azure SQL DatabaseAzure SQL Managed InstanceSQL-database in Fabric

Zie voor een inleiding tot Extended Events:

• Uitgebreide gebeurtenissen
• Snel aan de slag: Uitgebreide gebeurtenissen

De functieset, functionaliteit en gebruiksscenario's voor uitgebreide gebeurtenissen in Azure SQL Database, SQL Database in Fabric en Azure SQL Managed Instance zijn vergelijkbaar met wat beschikbaar is in SQL Server. De belangrijkste verschillen zijn:

• In Azure SQL Database, SQL Database in Fabric en Azure SQL Managed Instance gebruikt het event_file doel altijd blobs in Azure Storage, in plaats van bestanden op schijf.
  • In SQL Server kan het event_file doel bestanden op schijf of blobs in Azure Storage gebruiken.
• In Azure SQL Database en de SQL-database in Fabric zijn eventsessies altijd op databaseniveau. Dit betekent dat:
  • Een gebeurtenissessie in de ene database kan geen gebeurtenissen uit een andere database verzamelen.
  • Een gebeurtenis moet plaatsvinden in de context van een gebruikersdatabase die in een sessie moet worden opgenomen.
• In Azure SQL Managed Instance kunt u zowel server- als databasegebereikte gebeurtenissessies maken. We raden u aan voor de meeste scenario's servergerichte gebeurtenissessies te gebruiken.

Get started

Er zijn twee overzichtsvoorbeelden waarmee u snel aan de slag kunt met uitgebreide gebeurtenissen:

• Maak een gebeurtenissessie met een event_file doel in Azure Storage. In dit voorbeeld ziet u hoe u gebeurtenisgegevens vastlegt in een bestand (blob) in Azure Storage met behulp van het event_file doel en richtlijnen voor probleemoplossing voor veelvoorkomende fouten bevat. Gebruik deze optie als u vastgelegde gebeurtenisgegevens wilt behouden of als u logboeken wilt gebruiken in SQL Server Management Studio (SSMS) om vastgelegde gegevens te analyseren.
• Maak een event-sessie met een ring_buffer-doelobject in het geheugen. In dit voorbeeld ziet u hoe u de meest recente gebeurtenissen van een gebeurtenissessie in het geheugen vastlegt met behulp van het ring_buffer doel. Gebruik dit als een snelle manier om recente gebeurtenissen te bekijken tijdens ad-hoconderzoeken of probleemoplossing, zonder dat u vastgelegde gebeurtenisgegevens hoeft op te slaan.

Extended Events kunnen worden gebruikt om alleen-lezen replica's te monitoren. Zie leesquery’s op replica’s voor meer informatie.

Beste praktijken

Hanteer de volgende best practices om Extended Events veilig en betrouwbaar te gebruiken, zonder gevolgen voor de gezondheid van de database-engine en de prestaties van workloads.

• Als u het event_file doel gebruikt:
  • Afhankelijk van de gebeurtenissen die zijn toegevoegd aan een sessie, kunnen de bestanden die door het event_file doel worden geproduceerd, gevoelige gegevens bevatten. Controleer zorgvuldig RBAC-roltoewijzingen en de toegangsbeheerlijsten (ACL) in het opslagaccount en de container, inclusief overgenomen toegang, om te voorkomen dat onnodige leestoegang wordt verleend. Volg het principe van minimale bevoegdheden.
  • Gebruik een opslagaccount in dezelfde Azure-regio als de database of het beheerde exemplaar waarin u gebeurtenissessies maakt.
  • Lijn de redundantie van het opslagaccount af met de redundantie van de database, elastische pool of het beheerde exemplaar. Gebruik voor lokaal redundante bronnen LRS, GRS of RA-GRS. Gebruik ZRS, GZRS of RA-GZRS voor zone-redundante resources. Zie Azure Storage-redundantie voor meer informatie.
  • Gebruik geen andere blobtoegangslaag dan Hot.
  • Schakel de hiërarchische naamruimte voor het opslagaccount niet in.
• Als u een continu actieve gebeurtenissessie wilt maken die automatisch wordt gestart nadat elke database-engine opnieuw is opgestart (bijvoorbeeld na een failover of een onderhoudsbeurt), neemt u de optie gebeurtenissessie op in STARTUP_STATE = ON uw CREATE EVENT SESSION of ALTER EVENT SESSION instructies.
• Gebruik daarentegen STARTUP_STATE = OFF voor korte-termijngebeurtenissessies, zoals sessies die worden gebruikt bij ad-hoc probleemoplossing.
• Lees in Azure SQL Database geen impassegebeurtenissen uit de ingebouwde dl gebeurtenissessie. Als er een groot aantal impassegebeurtenissen is verzameld, kan het lezen met de functie sys.fn_xe_file_target_read_file() een fout in het geheugen veroorzaken in de master database. Dit kan van invloed zijn op het verwerken van aanmeldingen en leiden tot een storing in een toepassing. Zie Impassegrafieken verzamelen in Azure SQL Database met uitgebreide gebeurtenissen voor de aanbevolen manieren om impasses te bewaken.

Doelen voor evenementsessies

Zie Doelen voor uitgebreide gebeurtenissen voor meer informatie over de doelen voor uitgebreide gebeurtenissen die worden ondersteund in Azure SQL Database, SQL Database in Fabric, Azure SQL Managed Instance en SQL Server.

Transact-SQL verschillen

Wanneer u de instructie CREATE EVENT SESSION, ALTER EVENT SESSION en DROP EVENT SESSION uitvoert in SQL Server en in Azure SQL Managed Instance, gebruikt u de ON SERVER component. In Azure SQL Database gebruikt u in plaats daarvan de ON DATABASE component, omdat in Azure SQL Database-gebeurtenissessies databasebereik hebben.

Catalogusweergaven van Extended Events

Extended Events biedt verschillende catalogusweergaven. Catalogusweergaven vertellen u over metagegevens of definities van gebeurtenissessies. Deze weergaven geven geen informatie over exemplaren van actieve gebeurtenissessies.

Zie Uitgebreide weergaven van de gebeurteniscatalogus voor een lijst met catalogusweergaven voor elk platform.

Dynamische beheerweergaven voor Extended Events

Extended Events biedt verschillende dynamische beheerweergaven (DMV's). DMV's retourneren informatie over gestarte gebeurtenissessies.

Zie voor een lijst met DMV's voor elk platform Dynamische beheerweergaven voor uitgebreide gebeurtenissen.

Veelvoorkomende DMV's

Er zijn extra DMV's voor uitgebreide gebeurtenissen die gebruikelijk zijn voor Azure SQL Database, Azure SQL Managed Instance en SQL Server:

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

Beschikbare gebeurtenissen, acties en doelen

U kunt beschikbare gebeurtenissen, acties en doelen verkrijgen met behulp van deze query:

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

Zie machtigingen voor gedetailleerde machtigingen per platform.

Autorisatie en beheer van opslagcontainers

Wanneer u het event_file doel gebruikt met Azure Storage-blobs, moet de database-engine die de gebeurtenissessie uitvoert, specifieke toegang hebben tot de blobcontainer. U kunt deze toegang op een van de volgende manieren verlenen:

• Wijs de RBAC-rol Storage Blob Data Contributor toe aan de beheerde identiteit van de logische Azure SQL-server of het beheerde exemplaar van Azure SQL voor de container, en maak een referentie om de Database Engine te laten weten dat beheerde identiteit moet worden gebruikt voor verificatie.

  Als alternatief voor het toewijzen van de rol Inzender voor opslagblobgegevens kunt u de volgende RBAC-acties toewijzen:

  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

• Maak een SAS-token voor de container en sla het token op in een referentie.

  In Azure SQL Database moet u een referentie voor databasebereik gebruiken. Gebruik in Azure SQL Managed Instance en SQL Server een referentie binnen het serverbereik.

  Het SAS-token dat u voor uw Azure Storage-container maakt, moet voldoen aan de volgende vereisten:

  • De rwdl-machtigingen (Read, Write, Delete, List) hebben.
  • Gebruik een begin- en eindtijd die de volledige duur van de gebeurtenissessie beslaan.
  • Geen IP-adresbeperkingen.

Netwerkbeveiligingsperimeter (voorbeeld)

Network security perimeter (preview) zet een netwerktoegangsgrens rond Azure SQL Database en andere Azure platform as a service (PaaS) resources. Wanneer je een logische server koppelt aan een netwerkbeveiligingsperimeter (NSP), zijn de uitgaande verbindingen die Extended Events maakt met Azure Storage onderworpen aan de toegangsregels van de perimeter.

Hoe Extended Events netwerktoegang gebruikt

Extended Events maakt uitgaande verbindingen van de Database Engine naar Azure Storage in twee gevallen:

• Gebeurtenisdata schrijven. Wanneer je een gebeurtenissessie start met een event_file-doel dat naar een blob wijst, controleert de Database Engine de uitgaande toegang voordat de sessie begint, en opnieuw telkens wanneer de gebeurtenisbuffers naar de blob worden weggeschreven.
• Gebeurtenisgegevens lezen. Wanneer je sys.fn_xe_file_target_read_file of sys.fn_MSxe_read_event_stream aanroept met een blob-URL, controleert de Database Engine uitgaande toegang wanneer de functie initialiseert. SSMS roept sys.fn_MSxe_read_event_stream aan wanneer je vastgelegde gebeurtenisgegevens opent in de gebeurtenisviewer.

Inkomende TDS-verbindingen die worden gebruikt om gebeurtenissessies via T-SQL te beheren, hebben geen NSP-configuratie nodig die specifiek is voor uitgebreide gebeurtenissen. De CREATE EVENT SESSION, ALTER EVENT SESSION, en DROP EVENT SESSION en de leesfuncties draaien allemaal via een normale clientverbinding, dus ze volgen dezelfde inkomende toegangsregels als elke andere clientverbinding met de database.

Ondersteunde configuraties

Het gedrag hangt af van de toegangsmodus van de perimeter, of het opslagaccount zich in dezelfde perimeter bevindt als de logische server, en of twee verschillende perimeters met elkaar verbonden zijn.

Configureer uitgaande toegang tot het opslagaccount

Wanneer je een database configureert om Extended Events te gebruiken, kun je kiezen tussen managed identity en SAS-tokenauthenticatie . Het authenticatiemechanisme dat je kiest bepaalt of je een uitgaande toegangsregel nodig hebt.

1. Controleer de perimeterverbinding. Zoek in het Azure-portaal op Network Security Perimeter, selecteer je perimeter en selecteer vervolgens Associated Resources in het instellingenmenu om te bevestigen dat je server vermeld staat. Voor meer informatie, zie Netwerkbeveiligingsperimeter.
2. Kies je authenticatiemechanisme. Gebruik beheerde identiteitsauthenticatie. Een managed identity token bevat de claims die de perimeter nodig heeft, dus je hoeft geen outbound-regel toe te voegen en kunt de volgende stap overslaan.
3. Voeg een uitgaande toegangsregel toe (alleen SAS-token). Als je een SAS-token gebruikt en de perimeter staat in enforce-modus, voeg dan een outbound access-regel toe op het perimeterprofiel. Gebruik bijvoorbeeld een regeltype Volledig gekwalificeerde domeinnamen (FQDN) en de hostnaam van je opslagaccount als waarde.myxedata.blob.core.windows.net

In dit voorbeeld kun *.blob.core.windows.net je elk Azure Storage-account toestaan, maar die instelling staat uitgaande verbindingen toe naar opslagaccounts die je niet bezit. Gebruik waar mogelijk de specifieke hostnaam.

Houd de perimeter in overgangsmodus totdat je hebt bevestigd welke uitgaande regels je nodig hebt. In de overgangsmodus logt de perimeter de evaluaties van de regels zonder toegang te blokkeren, zodat je ontbrekende regels kunt vinden voordat ze storingen veroorzaken. Schakel over naar de verplichte modus nadat de regels zijn ingevoerd.

Beperkingen en gedragsverschillen

• De Database Engine controleert uitgaande toegang wanneer een sessie start en bij elke bufferflush. Als je een uitgaande regel verwijdert terwijl een sessie draait, stopt de sessie niet. Individuele buffer-schrijfacties beginnen in plaats daarvan te falen.
• Beheerde identiteiten en SAS-tokens zijn niet gelijk onder een perimeter. Een token voor beheerde identiteit bevat perimeterclaims en heeft dus geen uitgaande regel nodig. Een SAS-token bevat deze claims niet, dus heeft het in de afgedwongen modus een overeenkomende uitgaande regel nodig.
• Een geblokkeerde leesfunctie hoeft geen fout te veroorzaken. Wanneer een perimeter blokkeert sys.fn_xe_file_target_read_file of sys.fn_MSxe_read_event_stream, kan de functie fout 25759 of 25717 geven, of een lege resultaatset zonder fout teruggeven. Als je data verwacht maar geen rijen en geen fouten krijgt, controleer dan je uitgaande regels.

Fouten wanneer een perimeter de toegang blokkeert

Fout 25602 betekent dat het event_file doelwit niet kon initialiseren omdat de perimeter de uitgaande verbinding naar het opslagaccount blokkeerde:

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.

Fout 25759 betekent dat een perimeter een leesfunctie blokkeerde:

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

Fout 25717 betekent dat de toegang is ingetrokken terwijl een leesfunctie aan het lezen was. Omdat de Database Engine blobgegevens in chunks leest in plaats van hele bestanden te downloaden, kan deze fout halverwege een resultaatset optreden:

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

Om een van deze fouten op te lossen, schakel je over op beheerde identiteitsauthenticatie, voeg je een uitgaande FQDN-regel toe die overeenkomt met de hostnaam van het opslagaccount, of verplaats je het opslagaccount naar dezelfde perimeter als de logische server.

Voor meer diagnostische details over doelinitialisatie en buffer-schrijffouten, raadpleeg het Extended Events-enginelogboek:

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

Wijzigingen in perimeterassociaties en toegangsmoduswijzigingen verschijnen in het Azure Activity Log voor de logische server. Evaluaties van inkomende en uitgaande regels verschijnen in netwerkbeveiligingsperimeterdiagnoselogs.

Resourcebeheer

In Azure SQL Database wordt geheugenverbruik door uitgebreide gebeurtenissessies dynamisch beheerd door de database-engine om conflicten tussen resources te minimaliseren.

Er is een limiet voor het geheugen dat beschikbaar is voor gebeurtenissessies:

• In één database is het totale sessiegeheugen beperkt tot 128 MB.
• In een elastische pool worden afzonderlijke databases beperkt door de limieten voor individuele databases en in totaal kunnen ze niet groter zijn dan 512 MB.

Als u een foutbericht ontvangt dat verwijst naar een geheugenlimiet, zijn de corrigerende acties die u kunt ondernemen:

• Voer minder gelijktijdige eventsessies uit.
• Met behulp van CREATE en ALTER instructies voor gebeurtenissessies kunt u de hoeveelheid geheugen verminderen die u opgeeft in de MAX_MEMORY clausule voor de sessie.

Er is een limiet voor het aantal gestarte gebeurtenissessies in Azure SQL Database:

• In één database is de limiet 100.
• In een elastische pool is de limiet 100 sessies binnen het databasebereik per pool.

In dichte elastische pools kan het starten van een nieuwe uitgebreide gebeurtenissessie mislukken vanwege geheugenbeperkingen, zelfs als het totale aantal gestarte sessies lager is dan 100.

Als u het totale geheugen wilt vinden dat door een gebeurtenissessie wordt verbruikt, voert u de volgende query uit terwijl deze is verbonden met de database waar de gebeurtenissessie wordt gestart:

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

Als u het totale geheugen van de gebeurtenissessie voor een elastische pool wilt vinden, moet deze query worden uitgevoerd in elke database in de pool.

Verwante inhoud

• Uitgebreide gebeurtenissen
• Snel aan de slag: Uitgebreide gebeurtenissen
• Netwerkbeveiligingsperimeter voor Azure SQL Database (preview)