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:

• Eventi estesi
• Avvio rapido: Eventi estesi

Il set di funzionalità, le funzionalità e gli scenari di utilizzo per gli Eventi estesi nel Database SQL di Azure, nel database SQL in Fabric e in Istanza gestita di SQL di Azure sono simili a quelli disponibili 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 Archiviazione di Azure anziché i file su disco come destinazione.
  • In SQL Server la event_file destinazione può usare file su disco oppure BLOB in Archiviazione di Azure.
• In Database SQL di Azure e nel database SQL in Fabric, le sessioni di evento sono sempre limitate all'ambito del 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:

• Creare una sessione eventi con una destinazione event_file in Archiviazione di Azure. Questo esempio illustra come acquisire i dati degli eventi in un file (blob) in Archiviazione di Azure usando la event_filedestinazione e include indicazioni per la risoluzione dei problemi relativi agli errori comuni. Usare questa opzione se è necessario rendere persistenti i dati degli eventi acquisiti o se si vuole usare il Visualizzatore eventi in SQL Server Management Studio (SSMS) per analizzare i dati acquisiti.
• Creare una sessione eventi con una destinazione ring_buffer in memoria. Questo esempio illustra come acquisire gli eventi più recenti da una sessione di eventi in memoria usando la ring_buffer destinazione. Usare questo metodo come modo rapido per esaminare gli eventi recenti durante indagini o risoluzione dei problemi ad hoc, senza dover archiviare i dati degli eventi acquisiti.

Gli Extended Events possono essere utilizzati per monitorare le repliche di sola lettura. Per altre informazioni, vedi Query di lettura nelle 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. Verificare attentamente le assegnazioni di ruolo RBAC e gli elenchi di controllo di accesso (ACL) nell'account di archiviazione e nel contenitore, compreso l'accesso ereditato, per evitare di concedere 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.
  • Allinea 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 LRS, GRS o RA-GRS. Per le risorse con ridondanza della zona, usare ZRS, GZRS 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 di eventi in esecuzione continua che si avvii automaticamente dopo ogni riavvio del Motore di database (ad esempio, dopo un failover o un evento di manutenzione), includere l'opzione della sessione di eventi STARTUP_STATE = ON nelle istruzioni CREATE EVENT SESSION 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.
• Nel Database SQL di Azure, non leggere gli eventi di deadlock dalla sessione dl di eventi predefinita. 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.

Obiettivi della sessione evento

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 di 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 clausola ON DATABASE, perché in Database SQL di Azure le sessioni di eventi hanno ambito a livello di database.

Viste del catalogo di Extended Events

Extended Events offre diverse visualizzazioni del catalogo. Le viste del catalogo indicano i metadati o la definizione della sessione eventi. Queste viste non restituiscono informazioni sulle istanze di sessioni di eventi attive.

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

Viste a gestione dinamica di Extended Events

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

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

I 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:

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

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 Collaboratore ai dati dei BLOB di archiviazione all'identità gestita del server logico SQL di Azure o dell'istanza gestita 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 RBAC Storage Blob Data Contributor, è possibile assegnare le seguenti azioni RBAC:

  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 è necessario usare una credenziale con ambito a livello di database. In Istanza gestita di SQL di Azure e SQL Server, utilizzare una credenziale a livello di server.

  Il token SAS che si crea per il contenitore di Archiviazione di Azure deve soddisfare i requisiti seguenti:

  • Disporre delle autorizzazioni rwdl (Read, Write, Delete, List).
  • Impostare l'ora di inizio e l'ora di fine in modo che coprano l'intera durata della sessione dell'evento.
  • Non aver restrizioni degli indirizzi IP.

Perimetro di sicurezza di rete (anteprima)

Il perimetro di sicurezza di rete (anteprima) stabilisce un confine di accesso alla rete attorno a database SQL di Azure e altre risorse Azure platform as a service (PaaS). Quando si associa un server logico a un perimetro di sicurezza di rete (NSP), le connessioni in uscita che Extended Events effettua con Archiviazione di Azure sono soggette alle regole di accesso del perimetro.

Come gli Eventi Estesi utilizzano l'accesso alla rete

Extended Events effettua connessioni in uscita dal motore di database a Archiviazione di Azure in due casi:

• Scrivere dati sugli eventi. Quando inizi una sessione di eventi con un event_file target che punta a un blob, il motore di database controlla l'accesso in uscita prima che la sessione inizi, e di nuovo ogni volta svuota i buffer degli eventi al blob.
• Lettura dei dati degli eventi. Quando chiami sys.fn_xe_file_target_read_file o sys.fn_MSxe_read_event_stream con un URL blob, il motore di database controlla l'accesso in uscita quando la funzione si avvia. SSMS chiama sys.fn_MSxe_read_event_stream quando si aprono i dati degli eventi acquisiti nel visualizzatore eventi.

Le connessioni TDS in entrata usate per gestire le sessioni di eventi tramite T-SQL non necessitano di alcuna configurazione NSP specifica per gli Eventi Estesi. Le CREATE EVENT SESSIONistruzioni , ALTER EVENT SESSION, e DROP EVENT SESSION e le funzioni di lettura si eseguono tutte su una normale connessione client, quindi seguono le stesse regole di accesso in entrata di qualsiasi altra connessione client al database.

Configurazioni supportate

Il comportamento dipende dalla modalità di accesso del perimetro, dal fatto che l'account di archiviazione sia nello stesso perimetro del server logico e dal fatto che due perimetri diversi siano collegati tra loro.

Configura l'accesso in uscita all'account di archiviazione

Quando configuri un database per usare Eventi Estesi, puoi scegliere tra identità gestita e autenticazione del token SAS . Il meccanismo di autenticazione che scegli determina se è necessaria una regola di accesso in uscita.

1. Verifica l'associazione perimetrale. Nel portale Azure, cerca Perimetro di Sicurezza di Rete, seleziona il tuo perimetro e poi seleziona Risorse Associate dal menu Impostazioni per confermare che il tuo server sia elencato. Per ulteriori informazioni, vedi Perimetro di sicurezza di rete.
2. Scegli il meccanismo di autenticazione. Usa l'autenticazione dell'identità gestita. Un token di identità gestita include le attestazioni di cui ha bisogno il perimetro, quindi non è necessario aggiungere una regola in uscita ed è possibile saltare il passaggio successivo.
3. Aggiungi una regola di accesso in uscita (solo token SAS). Se usi un token SAS e il perimetro è in modalità applicata, aggiungi una regola di accesso in uscita sul profilo perimetrale. Usa un tipo di regola di nomi di dominio completamente qualificati (FQDN) e il nome host del tuo account di archiviazione come valore, myxedata.blob.core.windows.netad esempio.

In questo esempio, puoi usare *.blob.core.windows.net per consentire ogni account Archiviazione di Azure, ma quell'impostazione consente connessioni in uscita con account di storage che non possiedi. Usa il nome host specifico dove puoi.

Mantieni il perimetro in modalità transizione finché non confermi quali regole di uscita servono. In modalità transizione, il perimetro registra le valutazioni delle regole senza bloccare l'accesso, così puoi trovare le regole mancanti prima che causino guasti. Passa in modalità forzata una volta che le regole sono in vigore.

Limitazioni e differenze comportamentali

• Il motore di database controlla l'accesso in uscita quando una sessione inizia e ad ogni svuotamento del buffer. Se rimuovi una regola di uscita mentre una sessione è in corso, la sessione non si ferma. Le singole scritture nel buffer iniziano invece a non riuscire.
• Le identità gestite e i token SAS non sono equivalenti sotto un perimetro. Un token di identità gestito trasporta rivendicazioni perimetrali, quindi non ha bisogno di una regola in uscita. Un token SAS non trasporta queste rivendicazioni, quindi ha bisogno di una regola outbound corrispondente in modalità applicata.
• Una funzione di lettura bloccata potrebbe non generare un errore. Quando un perimetro blocca sys.fn_xe_file_target_read_file o sys.fn_MSxe_read_event_stream, la funzione può generare l'errore 25759 o 25717, oppure restituire un set di risultati vuoto senza errore. Se ti aspetti dati ma non ricevi righe né errori, controlla le tue regole in uscita.

Errori quando un perimetro blocca l'accesso

L'errore 25602 significa che il event_file target non ha potuto inizializzare perché il perimetro bloccava la connessione in uscita con l'account storage:

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.

L'errore 25759 significa che un perimetro ha bloccato una funzione di lettura:

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

L'errore 25717 significa che l'accesso è stato revocato mentre una funzione di lettura stava leggendo. Poiché il motore di database legge i dati blob in blocchi invece di scaricare interi file, questo errore può verificarsi a metà di un set di risultati:

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

Per risolvere uno qualsiasi di questi errori, si passa all'autenticazione dell'identità gestita, si aggiunge una regola FQDN in uscita che corrisponda al nome host dell'account di storage, oppure si sposta l'account di storage nello stesso perimetro del server logico.

Per ulteriori dettagli diagnostici sull'inizializzazione del target e i fallimenti nella scrittura del buffer, consulta il registro del motore Extended Events:

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

Le modifiche all'associazione del perimetro e alle modalità di accesso appaiono nel Registro Attività di Azure per il server logico. Le valutazioni delle regole in entrata e in uscita appaiono nei log diagnostici del perimetro di sicurezza di rete.

Governo 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.
• Quando si usano le istruzioni CREATE e ALTER per le sessioni di eventi, riduci la quantità di memoria specificata nella clausola MAX_MEMORY per la sessione.

Esiste un limite nel numero di sessioni di eventi 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.

Contenuti correlati

• Eventi estesi
• Avvio rapido: Eventi estesi
• Perimetro di sicurezza di rete per database SQL di Azure (preview)