Spåra och spåra aktivitet
En stor del av att underhålla databaser är prestandajustering. Samma loggfiler som du är van vid att granska i dina lokala databaser är fortfarande tillgängliga med Azure Database for MySQL/PostgreSQL.
När dina databaser migreras till Azure måste du fortsätta att granska loggfilerna för att säkerställa att databasernas prestanda upprätthålls.
I den här lektionen ser du var loggfilerna för PostgreSQL och MySQL lagras i Azure och vilken detaljnivå de innehåller.
Använda serverloggar för att spåra databasaktivitet
Azure Database for MySQL/PostgreSQL registrerar även diagnostikinformation i serverloggarna. Serverloggar är de interna meddelandeloggfilerna för MySQL och PostgreSQL (inte transaktionsloggfilerna, som inte är tillgängliga i Azure Database for MySQL/PostgreSQL). Dessa filer innehåller meddelanden, serverstatus och annan felinformation som du använder för att felsöka problem med dina databaser. Serverloggarna behålls i upp till sju dagar (mindre om den totala storleken på serverloggfilerna överstiger 7 GB).
Azure Database for MySQL och Azure Database for PostgreSQL registrerar olika detaljer i serverloggarna. I följande avsnitt beskrivs serverloggarna för varje tjänst separat.
Serverloggar i Azure Database for MySQL
I Azure Database for MySQL tillhandahåller serverloggen den information som normalt är tillgänglig i loggen för långsamma frågor och granskningsloggen på en MySQL-server.
Du använder informationen i loggen för långsamma frågor för att identifiera långsamma frågor. Som standard är loggen för långsamma frågor inaktiverad. Du aktiverar den genom att ange slow_query_log-serverparametern till PÅ. Du konfigurerar loggen för långsamma frågor för att avgöra vad som menas med en långsam fråga med hjälp av följande serverparametrar:
- log_queries_not_using_indexes. Den här parametern är antingen PÅ eller AV. Ställ in den på PÅ för att registrera alla frågor som sannolikt kommer att utföra en fullständig tabellgenomsökning i stället för en indexsökning.
- log_throttle_queries_not_using_indexes. Anger det maximala antalet långsamma frågor som inte använder index som kan loggas per minut.
- log_slow_admin_queries. Ange den här parametern till PÅ för att inkludera administrativa frågor som körs långsamt i loggen.
- long_query_time. Tröskelvärdet (i sekunder) för en fråga som ska betraktas som långsam körning.
När du har aktiverat loggen för långsamma frågor och granskningsloggen börjar loggfilerna visas på sidan Serverloggar för servern. En ny långsam frågelogg skapas varje dag. Klicka på en loggfil för att ladda ned den:
Om du vill aktivera granskningsloggning anger du audit_log_enabled-serverparametern till PÅ. Du konfigurerar granskningsloggning med följande parametrar:
- audit_log_events. Ange vilka händelser som ska granskas. I Azure-portalen innehåller den här parametern en listruta med händelser, till exempel CONNECTION, DDL, DML, ADMIN och andra.
- audit_log_exclude_users. Den här parametern är en kommaavgränsad lista över användare vars aktiviteter inte tas med i granskningsloggen.
Om du behöver bevara den långsamma frågeloggen och granskningsloggen i mer än sju dagar ser du till att de överförs till Azure Storage. Använd sidan Diagnostikinställningar för servern och välj sedan + Lägg till diagnostikinställning. På sidan Diagnostikinställningar väljer du Arkivera till ett lagringskonto, väljer ett lagringskonto där loggfilerna ska sparas (det här lagringskontot måste redan finnas), väljer MySqlSlowLogs och MySqlAuditLogs och anger en kvarhållningsperiod på upp till 365 dagar. Du kan ladda ned loggfilerna från Azure Storage när som helst under den här tiden. Välj Spara:
Långsamma frågeloggdata skrivs i JSON-format till blobar i en container med namnet insights-logs-mysqlslowlogs. Det kan ta upp till 10 minuter innan loggfilerna visas i Azure Storage. Granskningsposter lagras i blobcontainern insights-logs-mysqlslowlogs , återigen i JSON-format.
Serverloggar i Azure Database for PostgreSQL
I Azure Database for PostgreSQL innehåller serverloggen felloggar och frågeloggfiler. Använd informationen i dessa filer för att hitta källorna till eventuella fel och ineffektiva frågor.
Du aktiverar loggning genom att ange de olika log_ serverkonfigurationsparametrarna till PÅ. Dessa parametrar omfattar:
- log_checkpoints. En kontrollpunkt inträffar när varje datafil har uppdaterats med den senaste informationen från transaktionsloggen. Om det uppstår ett serverfel markerar den här punkten den tidpunkt då återställningen måste påbörjas genom att rulla framåt från transaktionsloggen.
- log_connection och log_disconnections. De här inställningarna registrerar varje lyckad anslutning och slutet av varje session.
- log_duration. Den här inställningen gör att varaktigheten för varje slutförd SQL-instruktion registreras.
- log_lock_waits. Den här inställningen gör att låsväntehändelser registreras. Låsväntningar kan orsakas av dåligt implementerade transaktioner i programkoden.
- log_statement_stats. Den här inställningen skriver kumulativ information om serverns prestanda till loggen.
Azure Database for PostgreSQL innehåller även ytterligare parametrar för att finjustera den information som registreras:
- log_error_verbosity. Den här inställningen anger den detaljnivå som registreras för varje loggat meddelande.
- log_retention_days. Det här är antalet dagar som servern behåller varje loggfil innan den tas bort. Standardvärdet är tre dagar och du kan ange det till högst sju dagar.
- log_min_messages och log_min_error_statement. Använd dessa parametrar för att ange varnings- och felnivåerna för inspelningssatser.
Precis som med Azure Database for MySQL är loggfilerna som genereras av Azure Database for PostgreSQL tillgängliga på sidan Serverloggar . Du kan också använda sidan Diagnostikinställningar för att kopiera loggarna till Azure Storage.
Spåra frågeprestanda
Query Store är ytterligare en funktion som tillhandahålls av Azure för att hjälpa dig att identifiera och spåra frågor som körs dåligt. Du använder den med Azure Database for MySQL och Azure Database for PostgreSQL.
Aktivera spårning av frågeprestanda
Query Store registrerar information i mysql-schemat i Azure Database for MySQL och i en databas med namnet azure_sys i Azure Database for PostgreSQL. Query Store kan samla in två typer av information– data om frågekörning och information om väntestatistik. Query Store är inaktiverat som standard. För att aktivera den:
- Om du använder Azure Database for MySQL anger du serverparametrarna query_store_capture_mode och query_store_wait_sampling_capture_mode till ALLA.
- Om du använder Azure Database for PostgreSQL anger du serverparametern pg_qs.query_capture_mode till ALL eller TOP och anger parametern pgms_wait_sampling.query_capture_mode till ALL.
Analysera frågeprestandadata
Du kan köra frågor mot tabellerna som används av Query Store direkt. Om du kör Azure Database for MySQL ansluter du till servern och kör följande frågor:
SELECT * FROM mysql.query_store;
SELECT * FROM mysql.query_store_wait_stats;
Om du använder Azure Database for PostgreSQL kör du följande frågor i stället:
SELECT * FROM query_store.qs_view;
SELECT * FROM query_store.pgms_wait_sampling_view;
I båda fallen visar den första frågan texten för varje fråga som nyligen körts och en mängd statistik om hur lång tid det tog att kompilera och köra frågan. Den andra frågan visar information om väntehändelser. En väntehändelse inträffar när en fråga hindras från att köras eftersom den kräver de resurser som innehas av en annan.
Om du undersöker Query Store direkt kan du generera egna anpassade rapporter och få en detaljerad inblick i hur systemet fungerar. Mängden tillgängliga data kan dock göra det svårt att förstå vad som händer. Azure Database for MySQL/PostgreSQL innehåller ytterligare två verktyg som hjälper dig att navigera i dessa data – Query Performance Insight och Query Rekommendationer.
Query Performance Insight är ett grafiskt verktyg som är tillgängligt på sidan Query Performance Insight för servern. Fliken Tidskrävande frågor visar statistiken för de mest långvariga frågorna. Du anger tidsperioden och zoomar in på inom några minuter. Förklaringen visar texten i varje fråga, tillsammans med varaktigheten och antalet gånger frågan kördes. Diagrammet ger en jämförande vy över varaktigheten för varje fråga. Du visar data efter genomsnittlig tid för varje fråga, men det är också lärorikt att visa den totala tiden (varaktighetskörningsantal * ) för varje fråga. Bilden nedan visar ett exempel:
På fliken Väntestatistik visas information om väntehändelsen för varje fråga. Du ser hur lång tid en fråga lägger på att vänta på olika resurser.
Väntehändelser delas vanligtvis in i tre kategorier:
- Lås väntar. Dessa händelser inträffar om en fråga försöker läsa eller ändra data som är låsta av en annan fråga. Om du upplever ett stort antal låsväntningar kontrollerar du om det finns långvariga transaktioner eller åtgärder som använder en mycket restriktiv isoleringsnivå.
- I/O väntar. Den här typen av väntetid inträffar om en fråga utför en betydande mängd I/O. Detta kan bero på en dåligt utformad fråga (kontrollera WHERE-satsen ), en ineffektiv kopplingsåtgärd eller en fullständig tabellgenomsökning på grund av ett index som saknas.
- Minnesvänte. En minnesvänte inträffar om det inte finns tillräckligt med minne för att bearbeta en fråga. Frågan kan försöka läsa en stor mängd data, eller så kan den blockeras av andra frågor som samlar minne. Återigen kan detta tyda på att index saknas, vilket gör att frågor läser hela tabeller i minnet.
Det är också mycket troligt att en form av väntetid utlöser en annan, så du kan inte nödvändigtvis undersöka dessa problem isolerat. Till exempel kan en transaktion som läser och uppdaterar data i olika tabeller bli föremål för minnesvänte. I sin tur kan den här transaktionen ha låsta data som gör att en annan transaktion ådrar sig en låsvänte.
Sidan Prestanda Rekommendationer för servern tar informationen som finns i Query Store och använder den för att ge rekommendationer för att justera databasen för de arbetsbelastningar som den upplever.