Dela via

Utökade händelser i Azure SQL

gäller för:Azure SQL DatabaseAzure SQL Managed InstanceSQL-databas i Fabric

En introduktion till Utökade händelser finns i:

Funktionsuppsättningar, funktioner och användningsscenarier för utökade händelser i Azure SQL Database, SQL Database i Fabric och Azure SQL Managed Instance liknar det som är tillgängligt i SQL Server. De största skillnaderna är:

  • I Azure SQL Database, SQL Database i Fabric och Azure SQL Managed Instance event_file använder målet alltid blobar i Azure Storage i stället för filer på disk.
    • I SQL Server event_file kan målet använda antingen filer på diskar eller blobar i Azure Storage.
  • I Azure SQL Database och SQL Database i Fabric är händelsesessioner alltid databasomfattande. Det innebär att:
    • En händelsesession i en databas kan inte samla in händelser från en annan databas.
    • En händelse måste inträffa i kontexten för en användardatabas för att ingå i en session.
  • I Azure SQL Managed Instance kan du skapa både serveromfattande och databasomfattande händelsesessioner. Vi rekommenderar att du använder händelsesessioner med serveromfattning för de flesta scenarier.

Get started

Det finns två genomgångsexempel som hjälper dig att snabbt komma igång med Extended Events:

  • Skapa en händelsesession med ett event_file mål i Azure Storage. Det här exemplet visar hur du samlar in händelsedata i en fil (blob) i Azure Storage med hjälp av event_file målet och innehåller felsökningsvägledning för vanliga fel. Använd detta om du behöver spara insamlade händelsedata, eller om du vill använda loggboken i SQL Server Management Studio (SSMS) för att analysera insamlade data.
  • Skapa en händelsesession med ett ring_buffer-målobjekt i minnet. Det här exemplet visar hur du avbildar de senaste händelserna från en händelsesession i minnet med hjälp av ring_buffer målet. Använd detta som ett snabbt sätt att titta på de senaste händelserna under ad hoc-undersökningar eller felsökning, utan att behöva lagra insamlade händelsedata.

Utökade händelser kan användas för att övervaka skrivskyddade repliker. Mer information finns i Läsa frågor om repliker.

Metodtips

Använd följande metodtips för att använda Utökade händelser på ett säkert, tillförlitligt sätt och utan att påverka databasmotorns hälsotillstånd och arbetsbelastningsprestanda.

  • Om du använder event_file målet:
    • Beroende på vilka händelser som läggs till i en session kan filerna som skapas av event_file målet innehålla känsliga data. Granska rbac-rolltilldelningar och åtkomstkontrollistor (ACL) på lagringskontot och containern, inklusive ärvd åtkomst, för att undvika onödig läsåtkomst. Följ principen om lägsta behörighet.
    • Använd ett lagringskonto i samma Azure-region som databasen eller den hanterade instansen där du skapar händelsesessioner.
    • Justera redundansen för lagringskontot med redundansen för databasen, den elastiska poolen eller den hanterade instansen. För lokalt redundanta resurser använder du LRS, GRS eller RA-GRS. För zonredundanta resurser använder du ZRS, GZRS eller RA-GZRS. Mer information finns i Azure Storage-redundans .
    • Använd inte någon annan blobåtkomstnivå än Hot.
    • Aktivera inte det hierarkiska namnområdet för lagringskontot.
  • Om du vill skapa en händelsesession som körs kontinuerligt och som startas automatiskt efter varje omstart av STARTUP_STATE = ON databasmotorn (till exempel efter en redundansväxling eller en underhållshändelse), inkluderar du alternativet händelsesession i dina CREATE EVENT SESSION eller ALTER EVENT SESSION -instruktioner.
  • Omvänt kan du använda STARTUP_STATE = OFF för kortsiktiga händelsesessioner, till exempel de som används i ad hoc-felsökning.
  • Läs inte dödlägeshändelser från den inbyggda händelsesessionen i dl Azure SQL Database. Om ett stort antal dödlägeshändelser samlas in kan läsning av dem med funktionen sys.fn_xe_file_target_read_file() orsaka ett out-of-memory-fel i master databasen. Detta kan påverka inloggningsbearbetningen och leda till ett programstopp. De rekommenderade sätten att övervaka dödlägen finns i Samla in dödlägesdiagram i Azure SQL Database med utökade händelser.

Mål för händelsesession

Mer information om extended events-mål som stöds i Azure SQL Database, SQL Database i Fabric, Azure SQL Managed Instance och SQL Server finns i Mål för utökade händelser.

Transact-SQL skillnader

När du kör uttrycken CREATE EVENT SESSION, ALTER EVENT SESSION och DROP EVENT SESSION i SQL Server och i Azure SQL Managed Instance använder ON SERVER du -satsen. I Azure SQL Database använder ON DATABASE du satsen i stället, eftersom händelsesessionerna i Azure SQL Database är databasomfattande.

Katalogvyer för utökade händelser

Extended Events innehåller flera katalogvyer. Katalogvyer berättar om händelsesessionsmetadata eller definition. Dessa vyer returnerar inte information om instanser av aktiva händelsesessioner.

En lista över katalogvyer för varje plattform finns i Katalogvyer för utökade händelser.

Vyer för dynamisk hantering av utökade händelser

Extended Events innehåller flera dynamiska hanteringsvyer (DMV:er). DMV:er returnerar information om startade händelsesessioner.

En lista över DMV:er för varje plattform finns i Vyer för dynamisk hantering av utökade händelser.

Vanliga DMV:er

Det finns ytterligare DMV:er för utökade händelser som är gemensamma för Azure SQL Database, Azure SQL Managed Instance och SQL Server:

Tillgängliga händelser, åtgärder och mål

Du kan hämta tillgängliga händelser, åtgärder och mål med hjälp av den här frågan:

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

Se behörigheter för detaljerade behörigheter per plattform.

Auktorisering och kontroll av lagringscontainer

När du använder event_file målet med Azure Storage-blobar måste databasmotorn som kör händelsesessionen ha specifik åtkomst till blobcontainern. Du kan bevilja den här åtkomsten på något av följande sätt:

  • Tilldela RBAC-rollen Storage Blob Data Contributor till den hanterade identiteten för den logiska Azure SQL-servern eller azure SQL-hanterad instans i containern och skapa en autentiseringsuppgift för att instruera databasmotorn att använda hanterad identitet för autentisering.

    Som ett alternativ till att tilldela RBAC-rollen Storage Blob Data Contributor kan du tilldela följande RBAC-åtgärder:

    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

  • Skapa en SAS-token för containern och lagra token i en autentiseringsuppgift.

    I Azure SQL Database måste du använda en databasomfattande autentiseringsuppgift. I Azure SQL Managed Instance och SQL Server använder du en autentiseringsuppgift med serveromfattning.

    DEN SAS-token som du skapar för din Azure Storage-container måste uppfylla följande krav:

    • Ha behörigheterna rwdl (Read, Write, Delete, List) .
    • Ha starttid och förfallotid som omfattar händelsesessionens livslängd.
    • Har inga IP-adressbegränsningar.

Resursstyrning

I Azure SQL Database styrs minnesförbrukningen av utökade händelsesessioner dynamiskt av databasmotorn för att minimera resurskonkurrensen.

Det finns en gräns för tillgängligt minne för händelsesessioner:

  • I en enskild databas är det totala sessionsminnet begränsat till 128 MB.
  • I en elastisk pool begränsas enskilda databaser av de enskilda databasgränserna och får totalt inte överstiga 512 MB.

Om du får ett felmeddelande som refererar till en minnesgräns kan du vidta följande åtgärder:

  • Kör färre samtidiga händelsesessioner.
  • Med hjälp av CREATE och ALTER instruktioner för händelsesessioner minskar du mängden minne som du anger i MAX_MEMORY -satsen för sessionen.

Note

I Utökade händelser MAX_MEMORY visas -satsen i två kontexter: när du skapar eller ändrar en session (på sessionsnivå) och när du använder ring_buffer målet (på målnivå). Ovanstående gränser gäller för minnet på sessionsnivå.

Det finns en gräns för antalet startade händelsesessioner i Azure SQL Database:

  • I en enskild databas är gränsen 100.
  • I en elastisk pool är gränsen 100 databasomfattande sessioner per pool.

Om du startar en ny utökad händelsesession i kompakta elastiska pooler kan det misslyckas på grund av minnesbegränsningar även när det totala antalet påbörjade sessioner är under 100.

Om du vill hitta det totala minne som förbrukas av en händelsesession kör du följande fråga när du är ansluten till databasen där händelsesessionen startas:

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

För att hitta det totala händelsesessionsminnet för en elastisk pool måste den här frågan köras i varje databas i poolen.

Relaterat innehåll