Condividi tramite


Eventi estesi nel database SQL di Azure

Si applica a:Database SQL di AzureIstanza gestita di SQL di AzureDatabase SQL in Fabric

Per un'introduzione agli eventi estesi, vedere:

I set di funzionalità, le funzionalità e gli scenari di utilizzo per gli eventi estesi nel database SQL di Azure, nel database SQL di Azure in Infrastruttura e in Istanza gestita di SQL di Azure sono simili a quanto disponibile in SQL Server. Le differenze principali sono:

  • Nel database SQL di Azure, nel database SQL di Fabric e nell'Istanza SQL gestita di Azure, event_file usa sempre i BLOB in Azure Storage anziché i file su disco come destinazione.
    • In SQL Server la event_file destinazione può usare file su disco oppure BLOB in Azure Storage.
  • Nel database SQL di Azure e nel database SQL di Fabric le sessioni di eventi sono sempre con ambito database. Ciò significa che:
    • Una sessione di eventi in un database non può raccogliere eventi da un altro database.
    • Un evento deve verificarsi nel contesto di un database utente da includere in una sessione.
  • In Istanza gestita di SQL di Azure è possibile creare sessioni di eventi con ambito server e con ambito database. È consigliabile usare sessioni di eventi con ambito server per la maggior parte degli scenari.

Get started

Esistono due esempi di procedura dettagliata che consentono di iniziare rapidamente a usare gli eventi estesi:

Gli eventi estesi possono essere usati per monitorare le repliche di sola lettura. Per altre informazioni, vedere Lettura query sulle repliche.

Procedure consigliate

Adottare le procedure consigliate seguenti per usare eventi estesi in modo sicuro, affidabile e senza influire sull'integrità del motore di database e sulle prestazioni del carico di lavoro.

  • Se si usa la event_file destinazione:
    • A seconda degli eventi aggiunti a una sessione, i file prodotti dalla event_file destinazione potrebbero contenere dati sensibili. Esaminare attentamente le assegnazioni di ruolo controllo degli accessi in base al ruolo e gli elenchi di controllo di accesso (ACL) nell'account di archiviazione e nel contenitore, incluso l'accesso ereditato, per evitare di concedere l'accesso in lettura non necessario. Seguire il principio dei privilegi minimi.
    • Usare un account di archiviazione nella stessa area di Azure del database o dell'istanza gestita in cui si creano sessioni di eventi.
    • Allineare la ridondanza dell'account di archiviazione con la ridondanza del database, del pool elastico o dell'istanza gestita. Per le risorse con ridondanza locale, usare l’archiviazione con ridondanza locale, l'archiviazione con ridondanza geografica o RA-GRS. Per le risorse SQL di Azure con ridondanza della zona, usare ZRS, archiviazione con ridondanza geografica della zona o RA-GZRS. Vedere Ridondanza di Archiviazione di Azure per i dettagli.
    • Non usare alcun livello di accesso BLOB diverso da Hot.
    • Non abilitare lo spazio dei nomi gerarchico per l'account di archiviazione.
  • Se si desidera creare una sessione eventi in esecuzione continua che viene avviata automaticamente dopo ogni motore di database riavvio (ad esempio, dopo un failover o un evento di manutenzione), includere l'opzione sessione eventi di STARTUP_STATE = ON nelle CREATE EVENT SESSION istruzioni o ALTER EVENT SESSION .
  • Al contrario, usare STARTUP_STATE = OFF per sessioni di eventi a breve termine, ad esempio quelle usate nella risoluzione dei problemi ad hoc.
  • In database SQL di Azure non leggere gli eventi deadlock dalla sessione eventi predefinitadl. Se è stato raccolto un numero elevato di eventi deadlock, la lettura con la funzione sys.fn_xe_file_target_read_file() può causare un errore di memoria insufficiente nel master database. Ciò potrebbe influire sull'elaborazione del login e causare un'interruzione del servizio. Per i modi consigliati per monitorare i deadlock, vedere Raccogliere grafici deadlock in database SQL di Azure con eventi estesi.

Destinazioni sessione eventi

Per altre informazioni sulle destinazioni degli eventi estesi supportate nel database SQL di Azure, nel database SQL di Azure in Infrastruttura, in Istanza gestita di SQL di Azure e in SQL Server, vedere Destinazioni per gli eventi estesi.

differenze Transact-SQL

Quando si eseguono le istruzioni CREATE EVENT SESSION, ALTER EVENT SESSION, e DROP EVENT SESSION in SQL Server e in Istanza gestita di SQL di Azure, si usa la ON SERVER clausola. In database SQL di Azure si usa invece la ON DATABASE clausola , perché in database SQL di Azure le sessioni di eventi sono con ambito database.

Viste del catalogo degli eventi estesi

Gli eventi estesi offrono diverse viste del catalogo. Le viste del catalogo indicano i metadati o la definizione della sessione eventi. Queste viste non restituiscono informazioni sulle istanze delle sessioni di eventi attivi.

Per un elenco delle viste del catalogo per ogni piattaforma, vedere Viste del catalogo eventi estesi.

Viste a gestione dinamica degli eventi estesi

Gli eventi estesi offrono diverse viste a gestione dinamica (DMV). Le DMV restituiscono informazioni sulle sessioni evento avviate.

Per un elenco di DMV per ogni piattaforma, vedere Viste a gestione dinamica degli eventi estesi.

DMV comuni

Esistono eventi estesi DMV aggiuntivi che sono comuni al database SQL di Azure, all’Istanza gestita di SQL di Azure e al SQL Server:

Eventi, azioni e destinazioni disponibili

È possibile ottenere eventi, azioni e destinazioni disponibili usando questa 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

Vedere le autorizzazioni dettagliate per ciascuna piattaforma.

Autorizzazione e controllo del contenitore di archiviazione

Quando si utilizza la destinazione event_file con i BLOB di Archiviazione di Azure, il motore del database che gestisce la sessione di eventi deve avere accesso specifico al contenitore di BLOB. È possibile concedere questo accesso in uno dei modi seguenti:

  • Assegnare il ruolo Controllo degli accessi in base al ruolo collaboratore ai dati dei BLOB di archiviazione all'identità gestita del server logico SQL di Azure o all'istanza gestita di SQL di Azure nel contenitore e creare una credenziale per indicare al motore di database di usare l'identità gestita per l'autenticazione.

    In alternativa all'assegnazione del ruolo Controllo degli accessi in base al ruolo collaboratore ai dati dei BLOB di archiviazione, è possibile assegnare le azioni di controllo degli accessi in base al ruolo seguenti:

    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
  • Creare un token di firma di accesso condiviso per il contenitore e archiviare il token in una credenziale.

    In database SQL di Azure si deve usare una credenziale con ambito database. In Istanza gestita di SQL di Azure e SQL Server, utilizzare una credenziale a livello di server.

    Il token di firma di accesso condiviso creato per il contenitore Archiviazione di Azure deve soddisfare i requisiti seguenti:

    • Disporre delle rwdl autorizzazioni (Read, WriteDelete, , List) .
    • Avere l'ora di inizio e l'ora di scadenza che includono la durata della sessione eventi.
    • Non aver restrizioni degli indirizzi IP.

Governance delle risorse

In database SQL di Azure, il consumo di memoria da parte delle sessioni di eventi estesi viene controllato dinamicamente dal motore di database per ridurre al minimo la contesa delle risorse.

Esiste un limite di memoria disponibile per le sessioni di eventi:

  • In un singolo database, la memoria totale della sessione è limitata a 128 MB.
  • In un pool elastico i singoli database sono limitati dai limiti del database singolo e, in totale, non possono superare i 512 MB.

Se viene visualizzato un messaggio di errore che fa riferimento a un limite di memoria, le azioni correttive che è possibile eseguire sono:

  • Eseguire meno sessioni di eventi simultanee.
  • Uso delle CREATE istruzioni e ALTER per le sessioni di eventi, ridurre la quantità di memoria specificata nella MAX_MEMORY clausola per la sessione.

Note

In Eventi estesi la MAX_MEMORY clausola viene visualizzata in due contesti: durante la creazione o la modifica di una sessione (a livello di sessione) e quando si usa la ring_buffer destinazione (a livello di destinazione). I limiti precedenti si applicano alla memoria a livello di sessione.

Esiste un limite al numero di sessioni evento avviate in database SQL di Azure:

  • In un database singolo, il limite è 100.
  • In un pool elastico, il limite è di 100 sessioni con ambito database per pool.

Nei pool elastici densi, l'avvio di una nuova sessione eventi estesa potrebbe non riuscire a causa di vincoli di memoria anche quando il numero totale di sessioni avviate è inferiore a 100.

Per trovare la memoria totale utilizzata da una sessione eventi, eseguire la query seguente durante la connessione al database in cui viene avviata la sessione eventi:

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

Per trovare la memoria totale della sessione eventi per un pool elastico, questa query deve essere eseguita in ogni database del pool.