Traccia e traccia attività

Completato

Una parte importante della gestione dei database è l'ottimizzazione delle prestazioni. Gli stessi file di log usati per esaminare i database locali sono ancora disponibili con Database di Azure per MySQL/PostgreSQL.

Dopo aver eseguito la migrazione dei database ad Azure, è necessario continuare a esaminare i file di log per garantire che le prestazioni dei database vengano mantenute.

In questa unità verranno visualizzati i file di log per PostgreSQL e MySQL archiviati in Azure e il livello di dettaglio che contengono.

Usare i log del server per tenere traccia dell'attività del database

Database di Azure per MySQL/PostgreSQL registra anche le informazioni di diagnostica nei log del server. I log del server sono i file di log dei messaggi nativi per MySQL e PostgreSQL (non i file di log delle transazioni, che non sono accessibili in Database di Azure per MySQL/PostgreSQL). Questi file contengono messaggi, stato del server e altre informazioni sull'errore usate per eseguire il debug dei problemi con i database. I log del server vengono conservati per un massimo di sette giorni (minore, se le dimensioni totali dei file di log del server superano i 7 GB).

Database di Azure per MySQL e Database di Azure per PostgreSQL registrano dettagli diversi nei log del server. Le sezioni seguenti descrivono i log del server per ogni servizio separatamente.

Log del server in Database di Azure per MySQL

In Database di Azure per MySQL, il log del server fornisce le informazioni normalmente disponibili nel log delle query lente e nel log di controllo su un server MySQL.

Le informazioni nel log delle query lente vengono usate per identificare le query a esecuzione lenta. Log query lente è disabilitato per impostazione predefinita. È possibile abilitarla impostando il parametro del server slow_query_logsu ON. È possibile configurare il log delle query lente per determinare il significato di una query lenta usando i parametri del server seguenti:

• log_queries_not_using_indexes. Questo parametro è ON o OFF. Impostarlo su ON per registrare tutte le query che probabilmente eseguono un'analisi completa della tabella anziché una ricerca di indice.
• log_throttle_queries_not_using_indexes. Specifica il numero massimo di query lente che non usano indici che possono essere registrati al minuto.
• log_slow_admin_queries. Impostare questo parametro su ON per includere query amministrative a esecuzione lenta nel log.
• long_query_time. La soglia (in secondi) oltre la quale una query viene considerata a esecuzione lenta.

Dopo aver abilitato il log delle query lente e il log di controllo, i file di log inizieranno a essere visualizzati nella pagina dei log del server per il server. Ogni giorno viene creato un nuovo log di query lente. Fare clic su un file di log per scaricarlo:

Per abilitare la registrazione di controllo, impostare il parametro audit_log_enabled server su ON. La registrazione di controllo viene configurata con i parametri seguenti:

• eventi_di_registro_di_verifica. Specificare gli eventi da controllare. Nel portale di Azure questo parametro fornisce un elenco a discesa di eventi, ad esempio CONNECTION, DDL, DML, ADMIN e altri.
• registro_di_verifica_escludi_utenti. Questo parametro è un elenco delimitato da virgole di utenti le cui attività non verranno incluse nel log di controllo.

Se è necessario mantenere il log di query lento e il log di controllo per più di sette giorni, si prevede che vengano trasferiti nell'archiviazione di Azure. Usare la pagina Impostazioni di diagnostica per il server e quindi selezionare + Aggiungi impostazione di diagnostica. Nella pagina Impostazioni di diagnostica selezionare Archivia in un account di archiviazione, selezionare un account di archiviazione in cui salvare i file di log (questo account di archiviazione deve esistere già), selezionare MySqlSlowLogs e MySqlAuditLogs e specificare un periodo di conservazione fino a 365 giorni. È possibile scaricare i file di log da Archiviazione di Azure in qualsiasi momento durante questo periodo. Selezionare Salva:

I dati di log di query lente verranno scritti in formato JSON nei BLOB in un contenitore denominato insights-logs-mysqlslowlogs. La visualizzazione dei file di log nell'archiviazione di Azure può richiedere fino a 10 minuti. I record di controllo vengono archiviati nel contenitore BLOB insights-logs-mysqlslowlogs , anche in formato JSON.

Log del server in Database di Azure per PostgreSQL

In Database di Azure per PostgreSQL il log del server contiene i file di log degli errori e di log delle query. Usare le informazioni contenute in questi file per individuare le origini di eventuali errori e query inefficienti.

Per abilitare la registrazione, impostare i vari parametri di configurazione del server log_su ON. Questi parametri includono:

• log_checkpoints. Un checkpoint si verifica ogni volta che ogni file di dati è stato aggiornato con le informazioni più recenti del log delle transazioni. In caso di errore del server, questo punto contrassegna il momento in cui il ripristino deve iniziare eseguendo il roll forward dal log delle transazioni.
• log_connection e log_disconnections. Queste impostazioni registrano ogni connessione riuscita e la fine di ogni sessione.
• log_duration. Questa impostazione determina la registrazione della durata di ogni istruzione SQL completata.
• log_lock_waits. Questa impostazione determina la registrazione degli eventi di attesa di blocco. Le attese di blocco possono essere causate da transazioni non correttamente implementate nel codice dell'applicazione.
• log_statement_stats. Questa impostazione scrive informazioni cumulative sulle prestazioni del server nel log.

Database di Azure per PostgreSQL fornisce anche altri parametri per ottimizzare le informazioni registrate:

• log_error_verbosity. Questa impostazione specifica il livello di dettaglio registrato per ogni messaggio registrato.
• log_retention_days. Numero di giorni in cui il server conserva ogni file di log prima di rimuoverlo. Il valore predefinito è tre giorni ed è possibile impostarlo su un massimo di sette giorni.
• log_min_messages e log_min_error_statement. Usare questi parametri per specificare i livelli di avviso e di errore per le istruzioni di registrazione.

Come per Database di Azure per MySQL, i file di log generati da Database di Azure per PostgreSQL sono disponibili nella pagina dei log del server . È anche possibile usare la pagina Impostazioni di diagnostica per copiare i log nell'archiviazione di Azure.

Tenere traccia delle prestazioni delle query

Query Store è una funzionalità aggiuntiva fornita da Azure per identificare e tenere traccia delle query in esecuzione in modo non adeguato. È possibile usarlo con Database di Azure per MySQL e Database di Azure per PostgreSQL.

Abilitazione del rilevamento delle prestazioni delle query

Query Store registra le informazioni nello schema mysql in Database di Azure per MySQL e in un database denominato azure_sys in Database di Azure per PostgreSQL. Query Store può acquisire due tipi di informazioni, ovvero dati sull'esecuzione di query e informazioni sulle statistiche di attesa. Query Store è disabilitato per impostazione predefinita. Per abilitarlo:

• Se si utilizza Database di Azure per MySQL, impostare i parametri del server query_store_capture_mode e query_store_wait_sampling_capture_mode su "ALL".
• Se si usa Database di Azure per PostgreSQL, impostare il parametro del server pg_qs.query_capture_mode su ALL o TOP e impostare il parametro pgms_wait_sampling.query_capture_mode su ALL.

Analisi dei dati sulle prestazioni delle query

È possibile eseguire query sulle tabelle usate direttamente da Query Store. Se si esegue Database di Azure per MySQL, connettersi al server ed eseguire le query seguenti:

SELECT * FROM mysql.query_store;

SELECT * FROM mysql.query_store_wait_stats;

Se si usa Database di Azure per PostgreSQL, eseguire invece le query seguenti:

SELECT * FROM query_store.qs_view;

SELECT * FROM query_store.pgms_wait_sampling_view;

In entrambi i casi, la prima query visualizzerà il testo per ogni query eseguita di recente e una serie di statistiche sulla durata della compilazione ed esecuzione della query. La seconda query visualizza informazioni sugli eventi di attesa. Un evento di attesa si verifica quando viene impedita l'esecuzione di una query perché richiede le risorse contenute in un altro.

Se si esamina direttamente Query Store, è possibile generare report personalizzati e ottenere informazioni dettagliate sul funzionamento del sistema. Tuttavia, la quantità di dati disponibili può rendere difficile comprendere cosa sta accadendo. Database di Azure per MySQL/PostgreSQL offre due strumenti aggiuntivi che consentono di esplorare questi dati: Analisi delle prestazioni delle query e Consigli per le query.

Approfondimenti sulle prestazioni di query è un'utilità grafica, disponibile nella pagina Approfondimenti sulle prestazioni di query per il server. Nella scheda Query in esecuzione prolungata vengono visualizzate le statistiche per le query con la durata d'esecuzione più lunga. Si specifica il periodo di tempo e si esegue lo zoom avanti in pochi minuti. La legenda mostra il testo di ogni query, insieme alla durata e al numero di esecuzioni della query. Il grafico offre una visualizzazione comparativa della durata di ogni query. I dati vengono visualizzati in base al tempo medio per ogni query, ma è anche consigliabile visualizzare il tempo totale (numero di esecuzioni di durata * ) per ogni query. L'immagine seguente mostra un esempio:

Nella scheda Statistiche attesa vengono visualizzate le informazioni sull'evento di attesa per ogni query. Si noterà la quantità di tempo impiegato da una query in attesa di varie risorse.

Gli eventi di attesa in genere rientrano in tre categorie:

• Attese di blocco. Questi eventi si verificano se una query tenta di leggere o modificare i dati bloccati da un'altra query. Se si verifica un numero elevato di attese di blocco, verificare la presenza di transazioni a esecuzione prolungata o operazioni che usano un livello di isolamento estremamente restrittivo.
• Attese di I/O. Questo tipo di attesa si verifica se una query esegue una quantità significativa di I/O. Ciò potrebbe essere dovuto a una query non progettata correttamente (controllare la clausola WHERE ), a un'operazione di join inefficiente o a un'analisi completa della tabella causata da un indice mancante.
• Attese di memoria. Un'attesa di memoria si verifica se è disponibile memoria insufficiente per elaborare una query. La query potrebbe tentare di leggere una grande quantità di dati oppure potrebbe essere bloccata da altre query che recuperano memoria. Anche in questo caso, ciò potrebbe indicare che gli indici sono mancanti, causando la lettura di intere tabelle in memoria.

È anche molto probabile che una forma di attesa attivi un'altra, quindi non è necessariamente possibile esaminare questi problemi in isolamento. Ad esempio, una transazione che legge e aggiorna i dati in tabelle diverse potrebbe essere soggetta a un'attesa di memoria. A sua volta, questa transazione potrebbe avere dati bloccati che causano l'incorrere in un'altra transazione in un'attesa di blocco.

La pagina Raccomandazioni sulle prestazioni per il server accetta le informazioni contenute in Query Store e la usa per fornire raccomandazioni per ottimizzare il database per i carichi di lavoro che si sta riscontrando.