Uitgebreide gebeurtenissen in Azure SQL

2025-09-24

van toepassing op:Azure SQL Database Azure SQL Managed Instance SQL-database in Fabric

Zie voor een inleiding tot 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 SQL Database in Fabric zijn gebeurtenissessies altijd databasebereik. 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. Voor de meeste scenario's raden we u aan om gebeurtenissessies met serverbereik 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.

Uitgebreide gebeurtenissen kunnen worden gebruikt om alleen-lezen replica's te bewaken. Zie Leesquery's op replica's voor meer informatie.

Beste praktijken

Gebruik de volgende aanbevolen procedures om uitgebreide gebeurtenissen veilig, betrouwbaar en zonder invloed te hebben op de status en prestaties van de database-engine.

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 LRS, GRS of RA-GRS voor lokaal redundante resources. 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 gebeurtenissessies

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.

Weergaven van uitgebreide gebeurtenissencatalogus

Uitgebreide gebeurtenissen bieden verschillende catalogusweergaven. Catalogusweergaven vertellen u over metagegevens of definities van gebeurtenissessies. Deze weergaven retourneren geen informatie over exemplaren van actieve gebeurtenissessies.

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

Dynamische beheerweergaven voor uitgebreide gebeurtenissen

Uitgebreide gebeurtenissen bieden 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.

Algemene DMV's

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

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 Inzender voor opslagblobgegevens toe aan de beheerde identiteit van de logische Azure SQL-server of het met Azure SQL beheerde exemplaar in de container en maak een referentie om de Database Engine opdracht te geven beheerde identiteit te gebruiken 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:
- rwdl De machtigingen (Read, Write, Delete, List) hebben.
- De begin- en verlooptijd hebben die de levensduur van de gebeurtenissessie omvat.
- Geen IP-adresbeperkingen.

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 gebeurtenissessies uit.
Met behulp van CREATE en ALTER instructies voor gebeurtenissessies vermindert u de hoeveelheid geheugen die u opgeeft in de MAX_MEMORY component voor de sessie.

Note

In uitgebreide gebeurtenissen wordt de component weergegeven in twee contexten: bij het MAX_MEMORY maken of wijzigen van een sessie (op sessieniveau) en bij het gebruik van het ring_buffer doel (op doelniveau). De bovenstaande limieten gelden voor het geheugen op sessieniveau.

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.

Feedback

Is deze pagina nuttig?