Eventi estesi in database SQL di Azure e Istanza gestita di SQL di Azure

Si applica a:database SQL di Azure Istanza gestita di SQL di Azure

Per un'introduzione agli eventi estesi, vedere:

• Eventi estesi
• Guida introduttiva: Eventi estesi

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

• La event_file destinazione usa sempre i BLOB in Archiviazione di Azure, anziché i file su disco.
• In database SQL di Azure 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.

Attività iniziali

Esistono due esempi utili per iniziare a usare eventi estesi in database SQL di Azure e Istanza gestita di SQL di Azure rapidamente:

• Creare una sessione 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_file destinazione. 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 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 eventi estesi possono essere usati per monitorare le repliche di sola lettura. Per altre informazioni, vedere Leggere le query sulle repliche.

Procedure consigliate

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

• Se si usa la event_file destinazione:
  • Non impostare l'opzione EVENT_RETENTION_MODE su NO_EVENT_LOSS. Ciò potrebbe causare timeout della connessione e ritardi di failover tra gli altri problemi, che influiscono sulla disponibilità del database o dell'istanza gestita.
  • 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 l'archiviazione con ridondanza geografica e accesso in lettura. Per le risorse con ridondanza della zona, usare archiviazione con ridondanza della zona, archiviazione con ridondanza della zona o archiviazione con ridondanza geografica e accesso in lettura. Per informazioni dettagliate, vedere ridondanza Archiviazione di Azure.
  • Non usare alcun livello di accesso BLOB diverso da Hot.
• 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 dell'account di accesso e causare un'interruzione dell'applicazione. Per i modi consigliati per monitorare i deadlock, vedere Raccogliere grafici deadlock in database SQL di Azure con eventi estesi.

Destinazioni sessione eventi

database SQL di Azure e Istanza gestita di SQL di Azure supportano le destinazioni seguenti:

• event_file destinazione. Scrive buffer completi in un BLOB in un contenitore Archiviazione di Azure.
• ring_buffer destinazione. Contiene i dati dell'evento in memoria fino a quando non vengono sostituiti da nuovi dati dell'evento.
• event_counter destinazione. Conta tutti gli eventi che si verificano durante una sessione di eventi estesi.
• destinazione istogramma . Conta le occorrenze di valori diversi di campi o azioni in bucket separati.
• event_stream. Flussi dati dell'evento in un'applicazione .Net.

Differenze di Transact-SQL

Quando si eseguono le istruzioni CREATE EVENT edizione Standard SSION, ALTER EVENT edizione Standard SSION e DROP EVENT edizione Standard SSION 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 visualizzazioni del catalogo. Le viste del catalogo indicano i metadati o la definizione della sessione eventi. Queste visualizzazioni non restituiscono informazioni sulle istanze delle sessioni di eventi attive.

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 .

DMV comuni

Esistono DMV aggiuntivi per gli eventi estesi comuni a database SQL di Azure, Istanza gestita di SQL di Azure e 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

Come in SQL Server, è 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;

Autorizzazioni

In database SQL di Azure e Istanza gestita di SQL di Azure gli eventi estesi supportano un modello di autorizzazione granulare. È possibile concedere le autorizzazioni seguenti:

CREATE ANY DATABASE EVENT SESSION
DROP ANY DATABASE EVENT SESSION
ALTER ANY DATABASE EVENT SESSION
ALTER ANY DATABASE EVENT SESSION ADD EVENT
ALTER ANY DATABASE EVENT SESSION DROP EVENT
ALTER ANY DATABASE EVENT SESSION ADD TARGET
ALTER ANY DATABASE EVENT SESSION DROP TARGET
ALTER ANY DATABASE EVENT SESSION ENABLE
ALTER ANY DATABASE EVENT SESSION DISABLE
ALTER ANY DATABASE EVENT SESSION OPTION

CREATE ANY EVENT SESSION
DROP ANY EVENT SESSION
ALTER ANY EVENT SESSION
ALTER ANY EVENT SESSION ADD EVENT
ALTER ANY EVENT SESSION DROP EVENT
ALTER ANY EVENT SESSION ADD TARGET
ALTER ANY EVENT SESSION DROP TARGET
ALTER ANY EVENT SESSION ENABLE
ALTER ANY EVENT SESSION DISABLE
ALTER ANY EVENT SESSION OPTION

Per informazioni sui controlli di ognuna di queste autorizzazioni, vedere CREATE EVENT edizione Standard SSION, ALTER EVENT edizione Standard SSION e DROP EVENT edizione Standard SSION.

Tutte queste autorizzazioni sono incluse nell'autorizzazione per il database o l'istanza CONTROL gestita. In database SQL di Azure, il proprietario del database (dbo), i membri del db_owner ruolo del database e gli amministratori del server logico hanno l'autorizzazione del databaseCONTROL. In Istanza gestita di SQL di Azure i membri del ruolo del sysadmin server mantengono l'autorizzazione CONTROL per l'istanza.

Archiviazione l'autorizzazione e il controllo del contenitore

Quando si usa la event_file destinazione, i dati degli eventi vengono archiviati in BLOB in un contenitore Archiviazione di Azure. Il motore di database che esegue la sessione eventi deve avere accesso specifico a questo contenitore. Per concedere questo accesso, 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 database. In Istanza gestita di SQL di Azure usare una credenziale con ambito server.

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

• Disporre delle rwl autorizzazioni (Read, Write, List) .
• Avere l'ora di inizio e l'ora di scadenza che includono la durata della sessione eventi.
• Non sono previste restrizioni per gli 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.

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

• In un singolo database, 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.

Contenuto correlato

• Eventi estesi
• Guida introduttiva: Eventi estesi