Vänta Statistik och frågebutik

Det finns många blogginlägg på denna sida relaterade till väntestatistik; de är en av de viktigaste måtten du kan använda när du felsöker prestandaproblem i SQL Server. Väntestatistik gjordes tillgänglig i SQL Server 2005 och traditionellt har de representerat väntar på instansnivå via sys.dm_os_wait_statistics. Denna information är bra vid felsökning av systemprestanda i allmänhet, men när man tittar på frågeprestanda kunde vänteinformation endast ses när frågan kördes och om den väntade på en resurs via sys.dm_os_waiting_tasks. Datan i sys.dm_os_waiting_tasks är övergående (det är vad som väntar just nu) och är inte lätt att fånga och behålla under en frågas livslängd för prestandajustering vid ett senare tillfälle.

I SQL Server 2016 exponeras en ny DMV, sys.dm_exec_session_wait_stats, som ger information om väntan på en befintlig, aktiv session. Om du känner till session_id kan du spåra väntan på en fråga när den startar och när den slutförs (snapshot informationen i början och slutet av frågan och sedan ändra informationen). Utmaningen är att du måste känna till sessions_id för frågan, och du måste ställa in datafångst i förväg – vilket inte är trivialt när du är mitt uppe i ett högprioriterat problem.

Väntestatistikinformation finns i en faktisk körningsplan som börjar i SQL Server 2016 SP1. Endast de 10 bästa väntetiderna fångas, och det finns begränsningar vad gäller vad denna data representerar. Till exempel ignoreras CXPACKET och ingår inte i utdata, men det kommer att inkluderas i 2016 SP2 och 2017 CU3 och uppåt – där irrelevanta parallellismväntningar istället fångas upp av CXCONSUMER (som inte kommer att inkluderas i faktiska planväntningar).

Så hur kan vi se vad en specifik fråga verkligen väntar på? Vi kan använda Query Store! SQL Server 2017 inkluderar insamling av väntestatistikinformation i Query Store, och den här funktionen är också tillgänglig i Azure SQL Database. Väntestatistik är knuten till en frågeplan och fångas över tiden, precis som körtidsstatistiken. Tillägget av väntestatistikinformation i Query Store var den främsta funktionsbegäran efter den första lanseringen, och all den informationen tillsammans skapar kraftfulla felsökningsmöjligheter.

Komma igång

Insamling av väntastatistik i Query Store är aktiverat som standard för Azure SQL Database. När en ny databas skapas i SQL Server 2017, eller en databas uppgraderas från SQL Server 2014 eller tidigare, är Query Store inaktiverat som standard... och därmed insamling av väntestatistik inaktiveras. När en databas uppgraderas från SQL Server 2016, om den har Query Store aktiverat, kommer insamling av väntestatistik för Query Store att aktiveras vid uppgradering.

I demonstrationssyfte har jag återställt WideWorldImporters-databasen, sedan körde jag frågorna nedan för att aktivera Query Store och rensa bort all data som kan ha funnits tidigare (endast nödvändigt eftersom detta är en exempeldatabas):

ALTER DATABASE [WideWorldImporters] SET QUERY_STORE =PÅ;GO ALTER DATABASE [WideWorldImporters] SET QUERY_STORE ( OPERATION_MODE =READ_WRITE);GO ALTER DATABASE [WideWorldImporters] SET CLEAR_GOE; 

 Standardinställningarna används med satserna ovan, och om du vill ändra något av alternativen kan du göra det via UI eller via ALTER DATABASE-satsen. Nu när Query Store är aktiverat kommer den att börja samla in frågedata inklusive frågetexten, planerna, körtidsstatistik och väntestatistik. 
 
Titta på Väntestatistik
 

 För att generera vissa data kommer vi att skapa en lagrad procedur som kör en parallell fråga upprepade gånger.
 
SLUTA PROCEDUR OM FINNS [Försäljning].[OrderInfo]; GÅ SKAPA PROCEDUR [Försäljning].[OrderInfo]SOM BÖRJA MED 1=1 BÖRJA VÄLJ * FRÅN Sales.OrderLines ol INNER JOIN Warehouse.StockItems s ON ol.StockItemID .StockItemID OPTION (QUERYTRACEON 8649); SLUT
 

 Skapa sedan en .cmd-fil med följande kod:
 starta sqlcmd -S WIN2016\SQL2017 -d WideWorldImporters -q"EXECUTE [Försäljning].[OrderInfo];"
avsluta 

 Detta tillåter oss att inte kör SP i Management Studio, vilket skapar betydande ASYNC_NETWORK_IO-väntningar; vi vill se väntan relaterade till parallellism. Spara .cmd-filen och dubbelklicka sedan för att köra. Du kan generera ytterligare belastning genom att köra flera filer. Med det här scenariot kommer vi i första hand att se väntan relaterade till denna fråga, eftersom vi inte har någon annan arbetsbelastning. Kör gärna andra frågor mot WideWorldImporters-databasen samtidigt om du vill generera ännu mer väntedata.
 

 Efter flera minuter, stoppa kommandofilerna och expandera WideWorldImporters-databasen i Management Studio för att se Query Store-mappen och rapporterna nedan. Om du öppnar rapporten Top Resource Consuming Queries bör du se den lagrade procedurfrågan som den översta frågan.
 

 Standardvyn för den här rapporten visar frågor med den högsta totala varaktigheten. För att se frågor baserade på väntestatistik kan vi välja knappen Konfigurera och ändra den till Väntetid (ms). 
 Konfigurera-knapp i rapportvyn (överst till höger) Ändra resurs för rapporten Observera att du också kan konfigurera tidsintervallet och antalet returnerade frågor. För det här exemplet är den sista timmen acceptabel. 

 Om du håller muspekaren över fältet för den första frågan kan du se väntetiderna för frågan. Denna vy är för närvarande det enda sättet att se vänteinformationen i användargränssnittet, men ytterligare rapporter som är specifika för väntestatistik kommer förhoppningsvis i en framtida version av Management Studio. 
 

 Vänta information i användargränssnittet 
 

 De av er som har arbetat med väntestatistik ett tag kommer att märka att beskrivningarna av väntetyp är annorlunda. Det vill säga, istället för en CXPACKET väntetyp för att indikera parallellism, ser du helt enkelt "Parallellism Wait Type." Detta är en grundläggande skillnad i Query Store:Väntetyperna är grupperade i kategorier. Det finns över 900 olika väntetyper i SQL Server vid det här laget, och att försöka spåra var och en separat är extremt dyrt. Dessutom har Query Store utformats med alla dataproffs i åtanke – oavsett om du är expert på prestandajustering eller bara har börjat förstå hur SQL Server fungerar, bör du kunna använda Query Store för att enkelt hitta dåligt presterande frågor. Det innebär också att vänteinformationen blir lättare att förstå. För en fullständig lista över väntekategorier och väntetyperna inom, besök dokumentationen för sys.query_store_wait_stats.
 

 Du kan också se vänteinformation med T-SQL. Ett exempel på fråga är den nedan, som inkluderar frågan, plan_id(en) för den frågan och väntestatistik för ett givet tidsintervall:
 
VÄLJ TOP (10) [ws].[wait_category_desc], [ws].[avg_query_wait_time_ms], [ws].[total_query_wait_time_ms], [ws].[plan_id], [qt].[query_sql_text], [rsi ].[starttid], [rsi].[sluttid]FRÅN [sys].[query_store_query_text] [qt]GÅ MED [sys].[query_store_query] [q] PÅ [qt].[query_text_id] =[q].[query_text_id ]JOIN [sys].[query_store_plan] [qp] PÅ [q].[query_id] =[qp].[query_id]GÅ MED [sys].[query_store_runtime_stats] [rs] PÅ [qp].[plan_id] =[rs ].[plan_id]JOIN [sys].[query_store_runtime_stats_interval] [rsi] PÅ [rs].[runtime_stats_interval_id] =[rsi].[runtime_stats_interval_id]JOIN [sys].[query_store_wait_statsON] [ws]_runtime ] =[rs].[runtime_stats_interval_id] OCH [ws].[plan_id] =[qp].[plan_id]WHERE [rsi].[sluttid]> DATEADD(MINUT, -5, GETUTCDATE()) OCH [ws]. [execution_type] =0ORDER BY [ws].[avg_query_wait_time_ms] DESC;
 

 Frågeutdata 
 

 Även om du nu kan se alla väntan på en given fråga och dess plan, måste du fortfarande gräva vidare i prestanda för att till exempel förstå varför en fråga körs parallellt (när du kanske inte vill att den ska göra det) eller vad som kan blockera en fråga. Observera att väntestatistiken, precis som körtidsstatistiken, är kopplad till frågeplanen över tid. I den här utgången är intervalllängden för Query Store inställd på 10 minuter, så väntestatistiken är för varje plan för det 10-minutersintervallet (23:50 den 21 november 2017 till midnatt den 22 november 2017). Som standard är intervalllängden när du aktiverar Query Store 60 minuter.
 
Sammanfattning
 

 Väntestatistik, i kombination med individuella frågeplaner, gör Query Store till ett ännu mer formidabelt verktyg vid felsökning av system och frågeprestanda. Query Store är den enda funktionen som låter dig samla in fråge-, plan-, prestanda- och väntestatistik på en och samma plats. För er som är vana vid de otaliga väntetyperna bör anpassningen till kategorierna som används i Query Store vara smidig. För alla som är nya som väntar statistik är kategorierna ett bra ställe att börja förstå resursen som en fråga väntar på.