sql >> Database teknologi >  >> RDS >> Database

Vent Statistics and Query Store

Der er adskillige blogindlæg på dette websted relateret til ventestatistikker; de er en af ​​de vigtigste målinger, du kan bruge til fejlfinding af ydeevneproblemer i SQL Server. Ventestatistikker blev gjort tilgængelige i SQL Server 2005 og traditionelt har de repræsenteret ventetider på instansniveau via sys.dm_os_wait_statistics. Disse oplysninger er gode ved fejlfinding af systemets ydeevne generelt, men når man ser på forespørgselsydeevne, kunne venteoplysninger kun ses, når forespørgslen blev eksekveret, og hvis den ventede på en ressource via sys.dm_os_waiting_tasks. Dataene i sys.dm_os_waiting_tasks er forbigående (det er det, der venter lige nu) og er ikke lette at indfange og opbevare i hele en forespørgsel til justering af ydeevne på et senere tidspunkt.

I SQL Server 2016 afsløres en ny DMV, sys.dm_exec_session_wait_stats, som giver information om ventetider på en eksisterende, aktiv session. Hvis du kender session_id'et, kan du spore ventetider på en forespørgsel, når den starter, og når den afsluttes (snapshot oplysningerne i begyndelsen og slutningen af ​​forespørgslen og derefter ændre oplysningerne). Udfordringen er, at du skal kende session_id for forespørgslen, og du skal konfigurere datafangst på forhånd – hvilket ikke er trivielt, når du står midt i et højt prioriteret problem.

Ventestatistikoplysninger findes i en faktisk eksekveringsplan, der starter i SQL Server 2016 SP1. Kun de 10 bedste ventetider fanges, og der er begrænsninger med hensyn til, hvad disse data repræsenterer. For eksempel ignoreres CXPACKET og er ikke inkluderet i outputtet, men det vil blive inkluderet i 2016 SP2 og 2017 CU3 og opefter – hvor irrelevante parallelismeventer i stedet fanges af CXCONSUMER (som ikke vil indgå i egentlige planvents).

Så hvordan kan vi se, hvad en specifik forespørgsel virkelig venter på? Vi kan bruge Query Store! SQL Server 2017 inkluderer indsamling af ventestatistikoplysninger i Query Store, og denne funktionalitet er også tilgængelig i Azure SQL Database. Ventestatistikker er knyttet til en forespørgselsplan og fanges over tid, ligesom runtime-statistikken. Tilføjelsen af ​​oplysninger om ventestatistik i Query Store var den vigtigste funktionsanmodning efter den første udgivelse, og alle disse oplysninger skaber tilsammen effektive fejlfindingsmuligheder.

Kom godt i gang

Ventestatistikfangst i Query Store er som standard aktiveret for Azure SQL Database. Når en ny database oprettes i SQL Server 2017, eller en database opgraderes fra SQL Server 2014 eller tidligere, er Query Store deaktiveret som standard... og dermed er registreringen af ​​ventestatistikker deaktiveret. Når en database opgraderes fra SQL Server 2016, og hvis den har Query Store aktiveret, vil indsamling af ventestatistikker for Query Store blive aktiveret ved opgradering.

Til demonstrationsformål har jeg gendannet WideWorldImporters-databasen, hvorefter jeg udførte forespørgslerne nedenfor for at aktivere Query Store og rydde alle data, der kunne have eksisteret tidligere (kun nødvendigt, fordi dette er en eksempeldatabase):

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

Standardindstillingerne bruges sammen med sætningerne ovenfor, og hvis du vil ændre nogen af ​​mulighederne, kan du gøre det via brugergrænsefladen eller via ALTER DATABASE-sætningen. Nu hvor Query Store er aktiveret, begynder den at indfange forespørgselsdata, inklusive forespørgselsteksten, planerne, runtime-statistikker og ventestatistikker.

Ser på Vent-statistikker

For at generere nogle data, vil vi oprette en lagret procedure, der kører en parallel forespørgsel gentagne gange.

DROP PROCEDURE HVIS FINDER [Salg].[OrderInfo];GO OPRET PROCEDURE [Salg].[OrderInfo]ASBEGIN MENS 1=1 BEGYND SELECT * FRA Sales.OrderLines ol INNER JOIN Warehouse.StockItems s ON =ol.StockItemID .StockItemID OPTION (QUERYTRACEON 8649); SLUT

Opret derefter en .cmd-fil med følgende kode:

start sqlcmd -S WIN2016\SQL2017 -d WideWorldImporters -q"EXECUTE [Salg].[OrderInfo];"
afslut

Dette giver os mulighed for at ikke køre SP'en inde i Management Studio, hvilket skaber betydelige ASYNC_NETWORK_IO ventetider; vi ønsker at se ventetiden relateret til parallelitet. Gem .cmd-filen, og dobbeltklik derefter for at køre. Du kan generere yderligere belastning ved at køre flere filer. Med dette scenarie vil vi primært se ventetiden relateret til denne forespørgsel, da vi ikke har nogen anden arbejdsbyrde. Du er velkommen til at udføre andre forespørgsler mod WideWorldImporters-databasen samtidig, hvis du vil generere endnu flere ventedata.

Efter flere minutter skal du stoppe kommandofilerne og udvide WideWorldImporters-databasen i Management Studio for at se mappen Query Store og rapporterne nedenunder. Hvis du åbner rapporten Top ressourceforbrugende forespørgsler, bør du se den lagrede procedureforespørgsel som den øverste forespørgsel.

Standardvisningen for denne rapport viser forespørgsler med den højeste samlede varighed. For at se forespørgsler baseret på ventestatistikker kan vi vælge knappen Konfigurer og ændre den til Ventetid (ms).

Konfigurer-knap i rapportvisning (øverst til højre) Ændring af ressourcen til rapporten Bemærk, at du også kan konfigurere tidsintervallet og antallet af returnerede forespørgsler. For dette eksempel er den sidste time acceptabel.

Hvis du holder markøren over bjælken for den første forespørgsel, kan du se ventetiderne for forespørgslen. Denne visning er i øjeblikket den eneste måde at se venteoplysningerne på i brugergrænsefladen, men yderligere rapporter, der er specifikke for ventestatistikker, kommer forhåbentlig i en fremtidig udgivelse af Management Studio.

Ventoplysninger i brugergrænsefladen

De af jer, der har arbejdet med ventestatistikker i et stykke tid, vil bemærke, at beskrivelserne af ventetype er anderledes. Det vil sige, i stedet for en CXPACKET-ventetype for at indikere parallelitet, ser du blot "Parallelism Wait Type." Dette er en grundlæggende forskel i Query Store:Ventetyperne er grupperet i kategorier. Der er over 900 forskellige ventetyper i SQL Server på dette tidspunkt, og at prøve at spore hver enkelt separat er ekstremt dyrt. Derudover er Query Store designet med alle dataprofessionelle i tankerne - uanset om du er ekspert i justering af ydeevne eller bare er i gang med at forstå, hvordan SQL Server fungerer, bør du kunne bruge Query Store til nemt at finde dårligt ydende forespørgsler. Det betyder også at gøre venteoplysningerne nemmere at forstå. Besøg dokumentationen for sys.query_store_wait_stats for en komplet liste over ventekategorier og ventetyperne inden for.

Du kan også se venteoplysninger ved hjælp af T-SQL. Et eksempel på forespørgsel er nedenstående, som inkluderer forespørgslen, plan_id(erne) for den forespørgsel og ventestatistikker i et givet tidsinterval:

VÆLG 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]FRA [sys].[query_store_query_text] [qt]JOIN [sys].[query_store_query] [q] PÅ [qt].[query_text_id] =[q].[query_text_id ]JOIN [sys].[query_store_plan] [qp] TIL [q].[query_id] =[qp].[query_id]JOIN [sys].[query_store_runtime_stats] [rs] TIL [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]_stat. ] =[rs].[runtime_stats_interval_id] OG [ws].[plan_id] =[qp].[plan_id]HVOR [rsi].[sluttid]> DATEADD(MINUT, -5, GETUTCDATE()) OG [ws]. [execution_type] =0ORDER BY [ws].[avg_query_wait_time_ms] DESC;

Forespørgselsoutput

Selvom du nu kan se alle ventetider på en given forespørgsel og dens plan, vil du stadig skulle grave yderligere i ydeevnen for at forstå, for eksempel, hvorfor en forespørgsel kører parallelt (når du måske ikke ønsker det) eller hvad der kan blokere en forespørgsel. Bemærk, at ventestatistikken, ligesom runtime-statistikken, er knyttet til forespørgselsplanen over tid. I dette output er intervallængden for Query Store indstillet til 10 minutter, så ventestatistikken er for hver plan for det 10-minutters interval (23:50 den 21. november 2017 til midnat den 22. november 2017). Som standard er intervallængden, når du aktiverer Query Store, 60 minutter.

Oversigt

Ventestatistikker, kombineret med individuelle forespørgselsplaner, gør Query Store til et endnu mere formidabelt værktøj til fejlfinding af system og forespørgselsydeevne. Forespørgselsbutik er den eneste funktion, der giver dig mulighed for indbygget at fange forespørgsler, planlægning, ydeevnemålinger og ventestatistikker på ét sted. For dem af jer, der er vant til de utallige ventetyper, bør tilpasningen til de kategorier, der bruges i Query Store, være problemfri. For alle nye ventestatistikker er kategorierne et godt sted at begynde at forstå den ressource, som en forespørgsel venter på.


  1. Hvordan beskrives ydeevneproblemet i relationel database?

  2. Forespørgselsbutik:Viser indvirkningen af ​​indekser på indstik

  3. Konverter 'tid' til 'datetime2' i SQL Server (T-SQL-eksempler)

  4. Begrænsning af returneret post fra SQL-forespørgsel i Oracle