Attività di analisi e rilevamento

Completato

Una parte importante della gestione dei database riguarda l'ottimizzazione delle prestazioni. Gli stessi file di log usati per la revisione nei database locali rimangono disponibili con Database di Azure per MySQL/PostgreSQL.

Con i database migrati in Azure, è necessario continuare a esaminare i file di log per assicurarsi che le prestazioni dei database vengano mantenute.

In questa unità verrà illustrato dove i file di log per PostgreSQL e MySQL vengono archiviati in Azure e il livello di dettaglio in essi contenuto.

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 nel Database di Azure per MySQL/PostgreSQL). Questi file contengono messaggi, stato del server e altre informazioni sugli errori utili per eseguire il debug di problemi con i database. I log del server vengono conservati per un massimo di sette giorni (meno, se la dimensione totale dei file di log del server supera 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 separatamente i log del server per ogni servizio.

Log del server nel Database di Azure per MySQL

Nel Database di Azure per MySQL il log del server fornisce le informazioni normalmente disponibili in Log query lente e in Log di controllo in un server MySQL.

Le informazioni di Log query lente vengono usate per identificare le query con esecuzione lenta. Log query lente è disabilitato per impostazione predefinita. Per abilitare questa opzione, impostare il parametro del server slow_query_log su ATTIVATO. Log query lente viene configurato per determinare il significato di una query lenta usando i parametri del server seguenti:

• log_queries_not_using_indexes. Questo parametro può essere ATTIVATO o DISATTIVATO. Impostarlo su ATTIVATO per registrare tutte le query che potrebbero eseguire un'analisi completa della tabella anziché una ricerca nell'indice.
• log_throttle_queries_not_using_indexes. Specifica il numero massimo di query lente che non usano gli indici che possono essere registrati al minuto.
• log_slow_admin_queries. Impostare questo parametro su ATTIVATO per includere query amministrative con esecuzione lenta nel log.
• long_query_time. Indica la soglia (in secondi) per cui una query viene considerata a esecuzione lenta.

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

Per abilitare la registrazione di controllo, impostare il parametro del server audit_log_enabled su ATTIVATO. Configurare la registrazione di controllo con i parametri seguenti:

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

Se è necessario mantenere Log query lente e Log di controllo per più di sette giorni, è necessario trasferirli nell'archiviazione di Azure. Usare la pagina Impostazioni di diagnostica relativa al 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 essere già esistente), selezionare MySqlSlowLogs e MySqlAuditLogs e specificare un periodo di conservazione massimo di 365 giorni. È possibile scaricare i file di log da archiviazione di Azure in qualsiasi momento durante questo periodo di tempo. Selezionare Salva:

I dati di Log query lente verranno scritti in formato JSON nei BLOB in un contenitore denominato insights-logs-mysqlslowlogs. Possono essere necessari fino a 10 minuti per la visualizzazione dei file di log nella risorsa di archiviazione di Azure. I record di controllo vengono archiviati nel contenitore BLOB insights-logs-mysqlslowlogs, di nuovo in formato JSON.

Log di server in Database di Azure per PostgreSQL

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

Per abilitare la registrazione, impostare i vari parametri di configurazione del server log_ su ATTIVATO. Questi parametri includono:

• log_checkpoints. Ogni volta che i file di dati vengono aggiornati con le informazioni più recenti del log delle transazioni si verifica un checkpoint. Se si verifica un errore del server, questo punto contrassegna l'ora in cui deve iniziare il ripristino 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 comporta la registrazione della durata di ogni istruzione SQL completata.
• log_lock_waits. Questa impostazione comporta la registrazione degli eventi di attesa del blocco. Le attese di blocco possono essere causate da transazioni non correttamente implementate nel codice dell'applicazione.
• log_statement_stats. Questa impostazione consente di scrivere nel log informazioni cumulative sulle prestazioni del server.

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

• log_error_verbosity. Questa impostazione specifica il livello di dettaglio registrato per ogni messaggio registrato.
• log_retention_days. Indica il numero di giorni durante i quali il server mantiene 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 in Database di Azure per MySQL, i file di log generati da Database di Azure per PostgreSQL sono disponibili nella pagina Log del server. È anche possibile usare la pagina Impostazioni di diagnostica per copiare i log nella risorsa di archiviazione di Azure.

Tenere traccia delle prestazioni delle query

Query Store è una funzionalità aggiuntiva offerta da Azure che consente di identificare e tenere traccia delle query con esecuzione non corretta. Questa funzionalità viene usata in combinazione 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: i dati sull'esecuzione delle query e le informazioni sulle statistiche di attesa. Query Store è disabilitata per impostazione predefinita. Per abilitarla:

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

Analisi dei dati sulle prestazioni delle query

È possibile eseguire query sulle tabelle usate direttamente da Query Store. Se si usa 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 di esecuzione recente e un host di statistiche sul tempo impiegato per la compilazione e l'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 risorse contenute in un altro evento.

Se si esamina Query Store direttamente, è possibile generare report personalizzati e ottenere informazioni dettagliate sul funzionamento del sistema. La quantità di dati disponibili può, tuttavia, rendere difficile la comprensione di ciò che accade. Database di Azure per MySQL/PostgreSQL fornisce due strumenti aggiuntivi che consentono di esplorare questi dati: Informazioni dettagliate prestazioni query e Raccomandazioni sulle query.

Informazioni dettagliate prestazioni query è un'utilità grafica, disponibile dalla pagina Informazioni dettagliate prestazioni query relativa al server. Nella scheda Query a esecuzione prolungata vengono visualizzate le statistiche per le query con esecuzione prolungata. Si specifica il periodo di tempo e si seleziona lo zoom in avanti per visualizzare i dati entro pochi minuti. La legenda illustra il testo di ogni query, insieme alla durata e al numero di volte in cui la query è stata eseguita. Il grafico fornisce una visualizzazione comparativa della durata di ogni query. È possibile visualizzare i dati in base al tempo medio per ogni query, ma può essere utile visualizzare anche il tempo totale (durata * numero esecuzioni) per ogni query. L'immagine seguente illustra un esempio:

La scheda Statistiche di attesa mostra le informazioni sull'evento di attesa per ogni query. Verrà visualizzata la quantità di tempo impiegato da una query in attesa di varie risorse.

Gli eventi di attesa rientrano in genere in tre categorie:

• Attese di blocco. Questi eventi si verificano se una query sta tentando di leggere o modificare i dati bloccati da un'altra query. Se si verifica un numero elevato di attese di blocco, controllare l'eventuale presenza di transazioni a esecuzione prolungata o di operazioni che usano un livello di isolamento molto restrittivo.
• Attese di I/O. Questo tipo di attesa si verifica se una query sta eseguendo una quantità significativa di I/O. Questo problema può essere dovuto a una query progettata in modo non corretto (verificare la clausola WHERE ), a un'operazione di join non efficiente o a una scansione di tabella completa causata da un indice mancante.
• Attese di memoria. Un'attesa di memoria si verifica se non è disponibile memoria sufficiente per l'elaborazione di una query. È possibile che la query stia tentando di leggere una grande quantità di dati oppure che sia bloccata da altre query che occupano memoria. Anche in questo caso, ciò potrebbe indicare la mancanza di indici, causando la lettura in memoria di intere tabelle.

È anche molto probabile che una forma di attesa ne inneschi un'altra, pertanto non è 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 un'attesa di blocco in un'altra transazione.

La pagina Raccomandazioni per le prestazioni relativa al server prende le informazioni contenute in Query Store e le usa per fornire consigli per l'ottimizzazione del database in base ai carichi di lavoro che sta riscontrando.