Övervaka och felsöka prestanda

  • 10 minuter

Övervakning och felsökning är mycket viktiga element när det gäller att leverera konsekventa prestanda. Azure SQL har samma verktyg och funktioner för att övervaka och felsöka prestanda som SQL Server, och dessutom fler funktioner. Det gäller bland annat funktioner som dynamiska hanteringsvyer (DMV), utökade händelser och Azure Monitor. Det är också viktigt att du lär dig använda de här verktygen och funktionerna i olika prestandascenarier för Azure SQL. Dessa scenarier omfattar hög CPU-användning eller väntan på en resurs.

Verktyg och funktioner för att övervaka prestanda

Med Azure SQL får du övervaknings- och felsökningsfunktioner från Azures ekosystem, liksom bekanta verktyg från SQL Server. Vi går igenom dem i följande avsnitt.

Azure Monitor

Azure Monitor ingår i Azures ekosystem och Azure SQL är integrerat för att ge stöd för Azures mått, aviseringar och loggar. Du kan visualisera Azure Monitor-data i Azure Portal och program kan komma åt dessa data via Azure Event Hubs eller API:er. Precis som Windows Performance Monitor hjälper Azure Monitor dig att komma åt resursanvändningsstatistik för Azure SQL utan att använda SQL Server-verktyg.

Dynamiska hanteringsvyer (DMV)

Azure SQL tillhandahåller nästan samma DMV-infrastruktur som SQL Server, med några skillnader. DMV:er är en viktig del i prestandaövervakningen eftersom du kan visa viktiga SQL Server-prestandadata med hjälp av vanliga T-SQL-frågor. Du kan till exempel visa aktiva frågor, resursanvändning, frågeplaner och typer av resursväntan. Du får lära dig mer om DMV:er med Azure SQL senare i den här lektionen.

Utökade händelser

Azure SQL tillhandahåller nästan samma infrastruktur för utökade händelser som SQL Server, med några skillnader. Utökade händelser är en metod för att spåra viktiga körningshändelser i SQL Server som driver Azure SQL. När det gäller prestanda kan du med hjälp av utökade händelser spåra körningen av enskilda frågor. Du får lära dig mer om utökade händelser med Azure SQL senare i den här lektionen.

Förenklad frågeprofilering

Enkel profilering är en avancerad metod för att felsöka scenarier som kräver hämtning av den faktiska körningsplanen för förfrågningar under flygning och frågor med högt värde. På grund av dess låga omkostnader kan alla servrar som inte redan är CPU-bundna köra enkel profilering kontinuerligt och tillåta databasproffs att utnyttja alla körningskörningar när som helst. Du kan till exempel använda Aktivitetsövervakaren i SQL Server Management Studio (SSMS) eller fråga direkt sys.dm_exec_query_profiles eller sys.dm_exec_query_statistics_xml.

Du kan använda enkel frågeprofilering för att undersöka frågeplanen och körningstillståndet för en aktiv fråga. Det här är en central funktion när du ska felsöka frågeprestanda för instruktioner medan de körs. Med den här funktionen går det snabbare att lösa prestandaproblem jämfört med att använda verktyg som utökade händelser för att spåra frågeprestanda. Du kan komma åt enkel frågeprofilering via DMV:er och den är aktiverad som standard för Azure SQL som för SQL Server 2019 och senare versioner.

Felsökningsfunktioner för frågeplaner

I vissa situationer kan du behöva ytterligare information om frågeprestanda för en enskild T-SQL-instruktion. T-SQL SET-instruktioner som SHOWPLAN och STATISTICS kan ge den här informationen och stöds fullt ut för Azure SQL på samma sätt som för SQL Server.

Query Store

Query Store (frågearkivet) är ett historiskt register över prestandakörning för frågor som lagras i användardatabasen. Query Store är aktiverat som standard för Azure SQL och används för att tillhandahålla funktioner som automatisk plankorrigering och automatisk justering. SSMS-rapporter (SQL Server Management Studio) för arkivet är tillgängliga i Azure SQL. Använd de här rapporterna till att hitta de mest resurskrävande frågorna, skillnader i frågeplaner och de vanligaste väntetyperna när du undersöker scenarier med resursväntan.

Prestandavisualiseringar

För Azure SQL Database kan du se integrerad information om Query Store-prestanda i Azure-portalen med hjälp av visualiseringar. På så sätt kan du se en del av samma information för Query Store som med ett klientverktyg som SSMS. Använd alternativen Prestandaöversikt och Frågeprestandainsikt i Azure Portal.

DMV-information

DMV:er har varit drivande när det gäller övervakning och felsökning av prestanda för SQL Server i flera år. De vanligaste DMV:erna för SQL Server är tillgängliga för Azure SQL. Dessutom finns det ytterligare DMV:er som är specifika för Azure.

Azure SQL Managed Instance

Alla DMV:er för SQL Server är tillgängliga för SQL Managed Instance. Viktiga DMV:er som sys.dm_exec_requests och sys.dm_os_wait_stats används ofta för att undersöka frågeprestanda.

Systemvyn sys.server_resource_stats är specifik för Azure SQL Managed Instance och visar historisk resursanvändning. Det här är ett värdefullt verktyg för att se resursanvändning eftersom du inte har direkt åtkomst till operativsystemverktyg som Prestandaövervakaren.

Azure SQL Database

De flesta vanliga DMV:er som du behöver för prestanda, inklusive sys.dm_exec_requests och sys.dm_os_wait_stats, är tillgängliga. De här DMV:erna ger endast information om den specifika databasen, inte om alla databaser på en logisk server.

sys.dm_db_resource_stats DMV:en är specifik för Azure SQL Database och du kan använda den för att visa en historik över resursanvändningen för databasen. Använd den här DMV:n på samma sätt som du använder sys.server_resource_stats för en hanterad instans.

sys.elastic_pool_resource_stats DMV liknar sys.dm_db_resource_stats, men du kan använda den för att visa resursanvändning för elastiska pooldatabaser.

De DMV:er du behöver

Du behöver följande DMV:er i vissa prestandascenarier för Azure SQL:

  • sys.dm_io_virtual_file_stats är viktigt eftersom du inte har direkt åtkomst till operativsystemmått för I/O-prestanda per fil.
  • sys.dm_os_performance_counters är tillgängligt för både Azure SQL Database och SQL Managed Instance och visar vanliga prestandamått för SQL Server. Använd den här DMV:en för att visa information om PRESTANDAräknare för SQL Server som vanligtvis är tillgänglig i Prestandaövervakaren.
  • sys.dm_instance_resource_governance kan visa resursgränser för en hanterad instans. Du kan visa den här informationen för att se vad dina förväntade resursgränser bör vara utan att använda Azure Portal.
  • sys.dm_user_db_resource_governance kan visa vanliga resursgränser efter distributionsalternativ, tjänstnivå och storlek för din Azure SQL Database-distribution. Du kan visa den här informationen för att se vad dina förväntade resursgränser bör vara utan att använda Azure Portal.

DMV:er för djupare insikter

Med dessa DMV:er kan du få djupare insikt i resursgränser och resursstyrning för Azure SQL. De är inte avsedda för vanliga scenarier, men kan vara användbara när du detaljgranskar komplexa prestandaproblem. Mer information om dessa DMV:er finns i dokumentationen:

  • sys.dm_user_db_resource_governance_internal (endast SQL Managed Instance)
  • sys.dm_resource_governor_resource_pools_history_ex
  • sys.dm_resource_governor_workload_groups_history_ex

Information om utökade händelser

Funktionen för utökade händelser är spårningsmetoden för SQL Server. Utökade händelser för Azure SQL baseras på SQL Server-motorn och är därför nästan desamma för Azure SQL, med några anmärkningsvärda skillnader. Skillnaderna beskrivs i nästa avsnitt.

Utökade händelser i Azure SQL Database

Du kan använda utökade händelser för Azure SQL Database, precis som SQL Server, genom att skapa sessioner och använda händelser, åtgärder och mål. Här är några viktiga saker att tänka på när du skapar Extended Event-sessioner:

  • De vanligaste händelserna och åtgärderna stöds.
  • Du kan använda fil-, ring_buffer- och räknarmål.
  • Filmål kan användas med Azure Blob Storage eftersom du inte har åtkomst till de underliggande operativsystemdiskarna.

Du kan använda SSMS eller T-SQL för att skapa och starta sessioner. Du kan använda SSMS för att visa utökade måldata för händelsesessioner eller systemfunktionen sys.fn_xe_file_target_read_file.

Kommentar

Det går inte att använda SSMS för att visa aktiva data för Azure SQL Database.

Det är viktigt att känna till att alla utökade händelser som utlöses för dina sessioner är specifika för din databas och inte för hela den logiska servern.

Utökade händelser för Azure SQL Managed Instance

Utökade händelser kan användas i Azure SQL Managed Instance precis som i SQL Server genom att du skapar sessioner och använder händelser, åtgärder och mål. Här är några viktiga saker att tänka på när du skapar Extended Event-sessioner:

  • Alla händelser, mål och åtgärder stöds.
  • Filmål kan användas med Azure Blob Storage eftersom du inte har åtkomst till de underliggande operativsystemdiskarna.
  • Vissa händelser läggs till för SQL Managed Instance för att spåra händelser som är specifika för hanteringen och körningen av instansen.

Du kan använda SSMS eller T-SQL för att skapa och starta sessioner. Du kan använda SSMS för att visa utökade måldata för händelsesessioner eller systemfunktionen sys.fn_xe_file_target_read_file. Möjligheten för SSMS att visa livedata stöds för SQL Server och Azure SQL Managed Instance.

Prestandascenarier för Azure SQL

När du ska bestämma hur du ska använda verktyg och funktioner för övervakning och felsökning av prestanda är det viktigt att du studerar Azure SQL-prestanda med hjälp av scenarier.

Vanliga prestandascenarier

En vanlig teknik för felsökning av SQL Server-prestanda är att undersöka om ett prestandaproblem är Körs (hög CPU) eller Väntar (väntar på en resurs). Följande diagram visar ett beslutsträd för att avgöra om ett problem med SQL Server-prestanda körs eller väntar, och hur du använder prestandaverktyg för att fastställa orsaken och lösningen.

Diagram över körs jämfört med väntar.

Nu ska vi titta närmare på varje aspekt av diagrammet.

Körningsproblem och väntetider

Börja med att studera den övergripande resursanvändningen. För en vanlig SQL Server-distribution kan du använda verktyg som Prestandaövervakare i Windows eller högst upp i Linux. För Azure SQL kan du använda följande metoder:

  • Azure-portalen/PowerShell/aviseringar

    Azure Monitor har integrerade mått för att visa resursanvändning för Azure SQL. Du kan också ställa in aviseringar som söker efter olika resursanvändningstillstånd.

  • sys.dm_db_resource_stats

    För Azure SQL Database kan du titta på denna DMV för att visa CPU-, minnes- och I/O-resursanvändning för databasdistributionen. Denna DMV tar en ögonblicksbild av dessa data var 15:e sekund.

  • sys.server_resource_stats

    Denna DMV fungerar precis som sys.dm_db_resource_stats, men används till att visa resursanvändning angående CPU, minne och I/O i SQL Managed Instance. Denna DMV tar också en ögonblicksbild var 15:e sekund.

  • sys.dm_user_db_resource_governance

    För Azure SQL Database returnerar denna DMV de faktiska konfigurations- och kapacitetsinställningarna som används av resursstyrningsmekanismer i den aktuella databasen eller den elastiska poolen.

  • sys.dm_instance_resource_governance

    För Azure SQL Managed Instance returnerar denna DMV liknande information som sys.dm_user_db_resource_governance, men för den aktuella SQL Managed Instance.

Körs

Om du har fastställt att problemet är hög CPU-användning kallas detta ett scenario som körs. Ett scenario som körs kan handla om frågor som förbrukar resurser genom kompilering eller körning. Använd följande verktyg om du behöver ytterligare analyser:

  • Query Store

    Använd rapporterna om högst resursförbrukning i SSMS, katalogvyer i Query Store eller Query Performance Insight i Azure Portal (endast Azure SQL Database) om du vill hitta de frågor som förbrukar mest CPU-resurser.

  • sys.dm_exec_requests

    Använd denna DMV i Azure SQL för att få en ögonblicksbild av aktiva frågors tillstånd. Leta efter frågor med tillståndet RUNNABLE och väntetypen SOS_SCHEDULER_YIELD för att se om du har tillräckligt med processorkapacitet.

  • sys.dm_exec_query_stats

    Du kan använda den här DMV:n på ungefär samma sätt som Query Store för att hitta de mest resurskrävande frågorna. Tänk på att den bara är tillgänglig för frågeplaner som är cachelagrade, medan Query Store har en beständig prestandahistorik. Med denna DMV kan du också hitta frågeplanen för en cachelagrad fråga.

  • sys.dm_exec_procedure_stats

    Den ger information på samma sätt som sys.dm_exec_query_stats, men prestandainformationen kan visas för enskilda lagrade procedurer.

    När du har fastställt vilken fråga eller vilka frågor som förbrukar mest resurser kan du behöva undersöka om du har tillräckligt med CPU-resurser för din arbetsbelastning. Du kan felsöka frågeplaner med verktyg som förenklad frågeprofilering, SET-instruktioner, Query Store eller spårning av utökade händelser.

Väntar

Om prestandaproblemet inte verkar bero på hög CPU-resursanvändning kan det i stället orsakas av väntan på en resurs. Scenarier som innefattar väntan på resurser är:

  • I/O-väntetid
  • Låsväntetid
  • Spärrtid
  • Buffertpoolgränser
  • Minnestilldelningar
  • Borttagning av plancache

Om du vill utföra analys av väntande scenarier tittar du vanligtvis på följande verktyg:

  • sys.dm_os_wait_stats

    Använd den här DMV:n till att se de vanligaste väntetyperna för databasen eller instansen. Vilka väntetyper som är vanligast kan styra vilken åtgärd du ska vidta härnäst.

  • sys.dm_exec_requests

    Använd den här DMV:en för att hitta specifika väntetyper för aktiva frågor för att se vilken resurs de väntar på. Det här kan vara ett standardscenario med blockering beroende på andra användares lås.

  • sys.dm_os_waiting_tasks

    Du kan använda den här DMV:en för att hitta väntetyper för en viss uppgift för en specifik fråga som körs just nu, kanske för att se varför det tar längre tid än normalt. sys.dm_os_waiting_tasks innehåller den liveväntestatistik som sys.dm_os_wait_stats aggregeringar över tid.

  • Query Store

    Query Store innehåller rapporter och katalogvyer som visar en sammanställning av de väntetider som ligger i toppen för körning av frågeplaner. Det är viktigt att känna till att väntan på CPU är ett körningsproblem.

Dricks

Du kan använda utökade händelser för alla scenarier med körningsproblem eller väntetider. Då måste du konfigurera en session med utökade händelser för frågespårning. Den här metoden för att felsöka ett prestandaproblem är mer avancerad och kan returnera mycket information i utbyte mot mer prestandakostnader än DMV:er.

Scenarier som är specifika för Azure SQL

Det finns vissa prestandascenarier som är specifika för Azure SQL, både körningsproblem och väntetider. Några exempel är loggstyrning, arbetsgränser, väntetider på tjänstnivån Affärskritisk och väntetider specifika för en Hyperskala-distribution.

Loggstyrning

Azure SQL kan använda logghastighetsstyrning till att framtvinga resursgränser för användning av transaktionsloggen. Du kan behöva det här till att säkerställa resursgränser och för att uppfylla ett utlovat serviceavtal. Loggstyrning kan ses via följande väntetyper:

  • LOG_RATE_GOVERNOR: väntar på Azure SQL Database
  • POOL_LOG_RATE_GOVERNOR: väntar på elastiska pooler
  • INSTANCE_LOG_GOVERNOR: väntar på Azure SQL Managed Instance
  • HADR_THROTTLE_LOG_RATE*: väntar på svarstid för Affärskritisk och geo-replikering

Arbetsgränser

SQL Server använder en arbetarpool med trådar, men har gränser för maximalt antal arbetare. Program med ett stort antal samtidiga användare kan närma sig de arbetsgränser som tillämpas för Azure SQL Database och SQL Managed Instance:

  • Azure SQL Database har gränser som baseras på tjänstnivå och storlek. Om du överskrider den här gränsen visas ett fel för nya frågor.
  • Vid den aktuella tidpunkten använder max worker threadsSQL Managed Instance , så arbetare som har passerat den här gränsen kan se THREADPOOL väntetider.

Affärskritisk HADR-väntan

Om du använder tjänstnivån Affärskritisk kan du oväntat se följande väntetyper:

  • HADR_SYNC_COMMIT
  • HADR_DATABASE_FLOW_CONTROL
  • HADR_THROTTLE_LOG_RATE_SEND_RECV

Även om de här väntetiderna inte gör programmet långsammare kanske du inte förväntar dig att se dem. De visas vanligtvis bara om du använder en AlwaysOn-tillgänglighetsgrupp. På nivån Affärskritisk används tillgänglighetsgrupper för att implementera serviceavtal och tillgänglighetsfunktioner, de här väntetyperna är förväntade. Observera att långa väntetider kan indikera en flaskhals som långa I/O-svarstider eller eftersläpande repliker.

Hyperskala

Arkitekturen Hyperskala kan resultera i vissa unika väntetyper som inleds med prefixet RBIO (ett möjligt tecken på loggstyrning). Dessutom har DMV:er, katalogvyer och utökade händelser utökats så att de visar mått för sidserverläsningar.

I nästa övning får du lära dig hur du övervakar och löser ett prestandaproblem för Azure SQL med hjälp av de verktyg och kunskaper som du har fått i den här lektionen.