Utforska SQL Server 2016 Query Store GUI

Introduktion

Query Store är en ny funktion, introducerad i SQL Server 2016, som gör det möjligt för databasadministratörer att historiskt granska frågor och deras associerade planer med hjälp av det grafiska användargränssnittet som är tillgängligt i SQL Server Management Studio, samt att analysera frågeprestanda med hjälp av vissa Dynamic Management Views. Query Store är ett konfigurationsalternativ med databasomfattning och är tillgängligt för användning om kompatibilitetsnivån för databasen i fråga är 130.

Query Store liknar sådana teknologier i Oracles databasplattform som Automatic Workload Repository (AWR). AWR fångar upp prestandastatistik i ännu större skala än Query Store och låter en databasadministratör historiskt analysera prestanda. Sådana koncept som en lagringsperiod och lagringsgränser för insamlade data är tillgängliga i AWR-arkitekturen som de är i Query Store. Följande nyckelkonfigurationsalternativ är tillgängliga när du aktiverar Query Store:

Driftläge: Avgör om Query Store kommer att acceptera nyligen inhämtad data (ReadWrite-läge) eller bara lagra gammal data tillgänglig för rapporter (Skrivskyddat läge)
Dataspolningsintervall: Bestämmer hur ofta Query Store-minnesbuffertar töms till en disk. Kom ihåg att Query Store-data lagras i databasen där Query Store är aktiverat. Standardvärdet är 15 minuter.
Intervall för statistikinsamling: Bestämmer hur ofta query store runtime-statistik samlas in.
Maximal storlek: Bestämmer hur mycket arkivet för Query Store-statistik kan växa. Som standard är den 100 MB.
Query Store Capture Mode: Bestämmer granulariteten för frågefångst. ALLA, AUTO och INGEN är tillgängliga alternativ. Standardvärdet är AUTO.
Storleksbaserat rensningsläge: Avgör om Query Store kommer att tömma gamla data när den maximala storleken uppnås.
Inaktuell frågetröskel: Bestämmer antalet dagar som Query Store behåller data. Standardvärdet är inställt på trettio dagar.

Fig. 2 Frågebutiksalternativ

Frågearkiv är en databasomfattad funktion som kan aktiveras antingen genom att använda GUI (SQL Server Management Studio) eller genom att köra följande kommando:

ÄNDRA DATABAS [WideWorldImporters] SÄTT QUERY_STORE =PÅ;

Frågetelemetri som samlas in av Query Store lagras i systemtabeller i databasen där Query Store har aktiverats.

Exempel på frågor och standardrapporter

Än så länge finns allt jag skrivit från många andra källor; några av dem finns i referenssektionen.

I det här avsnittet ska vi titta lite djupare på vad vi faktiskt kan göra med Query Store när vi har aktiverat det med enkla exempel. Låt oss överväga följande två frågor:

Lista 1:Hämta poster med ett specifikt filter

använd WideWorldImportersgoselecta.ContactPersonID,a.OrderDate,a.DeliveryMethodID,a.Comments,b.OrderedOutersfromPurchasing.PurchaseOrders ainner join Purchasing.PurchaseOrderLines bon a.PurchaseOrderLines bon a.PurchaseOrderLines bon a.PurchaseOrderLines bon a.PurchaseOrderLines bon a.PurchaseOrderLines bon a.PurchaseOrderLines a.PurchaseOrderP00S02020000000 före>

Lista 2:Hämta poster med ett intervall

använd WideWorldImportersgoselecta.ContactPersonID,a.OrderDate,a.DeliveryMethodID,a.Comments,b.OrderedOutersfromPurchasing.PurchaseOrders ainner join Purchasing.PurchaseOrderLines bon a.PurchaseOrderLines bon a.PurchaseOrderLines bon a.PurchaseOrderLines bon a.PurchaseOrderLines like a.PurchasePurchaseID a.Upp.PurchaID a.0MLRechaID 0% /pre>

Var uppmärksam på den alternativa versionen av dessa frågor skrivna med versaler:

Lista 1:Hämta poster med ett specifikt filter (versaler)

ANVÄND WIDEWORLDIMPORTERSGOSELECTA.CONTACTPERSONID,A.ORDERDATE,A.DELIVERYMETHODID,A.COMMENTS,B.ORDEREDOUTERSFROMPURCHASING.PURCHASEORDERS AINNER JOIN JOIN PURCHASING.PURCHASEORDERLINES BOON A.ORPURCEIDCHARDER.2KÖP.KÖP.2KÖP.2KÖP.20KÖP 2002. före>

Lista 2:Hämta poster med ett område (versaler)

ANVÄND WIDEWORLDIMPORTERSGOSELECTA.CONTACTPERSONID,A.ORDERDATE,A.DELIVERYMETHODID,A.COMMENTS,B.ORDEREDOUTERSFROMPURCHASING.PURCHASEORDERS AINNER JOIN JOIN PURCHASING.PURCHASEORDERLINES BOON A.PURCEORDERLINES BOON A.PURCEIDPURCEORLIED00MLKÖP.KÖP.KÖP 2KÖP; /pre>

Som du kan se körde vi dessa frågor flera gånger med nyckelordet GO. Vi har alltså en rimlig mängd data att arbeta med. Det första vi bör vara medvetna om när vi använder Query Store för att analysera prestanda är att det finns sex standardrapporter inbyggda i SQL Server 2016 Query Store som visas i fig. 3.

Fig. 3 Query Store-rapporter

Namnen på rapporterna beskrivs i detalj i de tidigare artiklarna samt i Microsoft-dokumentationen. Data som tillhandahålls av dessa rapporter hämtas från de viktigaste dynamiska hanteringsvyerna nedan:

Plan Stats DMVs

sys.query_store_query_text – innehåller unika frågetexter som körs mot databasen
sys.query_store_plan – innehåller en uppskattad plan för frågan med kompileringstidsstatistiken
sys.query_context_settings – innehåller några unika kombinationer av planen som påverkar inställningar under vilka frågor exekveras
sys.query_store_query – frågeposter som spåras och tvingas fram separat i Query Store

DMV:er för körtidsstatistik

sys.query_store_runtime_stats_interval – Query Store delar upp tiden i automatiskt genererade tidsfönster (intervall) och lagrar aggregerad statistik för det intervallet för varje körd plan
sys.query_store_runtime_stats – innehåller samlad körtidsstatistik för utförda planer

Mycket mer information om hur du använder dessa DMV:er finns i den refererade Microsoft-dokumentationen. I den här artikeln kommer vi helt enkelt att använda GUI mestadels.

Som du kan se i fig. 4 granskar vi rapporten om övergripande resursförbrukning medan vi i nästa avsnitt kommer att begränsa oss till de frågor vi listade tidigare och den data vi kan hämta från dessa enkla frågor.

Fig. 4 Rapport om övergripande resursförbrukning

Analysera frågor med GUI

Några viktiga saker bör anses vara användbara när du använder Query Store-rapporterna:

Du kan konfigurera miljön genom att klicka på knappen som är markerad i Fig. 4. Fig. 5 visar oss de detaljer vi kan ändra för att passa vårt användningsfall:kriterier för data som ska returneras, datumintervall och datauppsättning som ska returneras. Om jag till exempel vill se det fråge-ID som är kopplat till de frågor jag granskar tydligt, skulle jag vilja minska min datamängd från standard Top 25 till Top 10, till exempel.
Fig. 5 Rapportkonfigurationsalternativ

Fig. 6 Topp 25 sökfrågor utförda den 1 maj 2018

Fig. 7 Topp 10 frågor utförda den 1 maj 2018
Stapeldiagrammen visar data mestadels med tid på x-axeln men du kan drilla ner en specifik datapunkt för att visa data baserat på fråge-ID:n. Varje fråge-ID bestämmer en specifik fråga. Det är viktigt att notera att en fråga identifieras unikt genom att hasha texten. Således skiljer sig en fråga med gemener från samma fråga i versaler. Detta bör vara allmänt känt:ad hoc-frågor är ett bekymmer för planens cache och de är också dåliga för frågearkivet både när det gäller utrymmesanvändning och korrekt analys.
Fig. 8 Fråga i lista 1 (gemener, fråga 42480)

Fig. 9 Fråga i lista 3 (versaler, fråga 42490)
Den tredje viktiga observationen är det faktum att när en datapunkt är grönmarkerad, hänför sig den detaljerade exekveringsplanen som visas i den nedre rutan till den datapunkten. I fig. 7 hänvisar denna datapunkt till fråge-ID 42481 som vi tidigare utförde (fullständig fråga visas i lista 2). Om du håller musen över denna datapunkt visas frågan, dess ID och antalet planer som är associerade med denna fråga (se fig. 8).
Fig. 10 Fråga 42481 Detaljer

Vår fråga exekverades 1391 gånger eftersom den är exakt fångad av Query Store och visas i y-axeln (utförandeantal) i stapeldiagrammet i Fig. 10. Rapporten hämtades medan batchen fortfarande kördes. Således har vi inte hela antalet (1500) som informerar oss om att det finns en realtidsfångning av data varje gång en fråga exekveras. På höger sida ser vi också planen som används för dessa multipla avrättningar (Plan 675). Vi kan verifiera detta med hjälp av frågan i Lista 5.

Anteckning 5

ANVÄND WideWorldImportersGOSELECT Txt.query_text_id, Txt.query_sql_text, Pl.plan_id, Qry.*FRÅN sys.query_store_plan AS PlJOIN sys.query_store_query AS Qry ON Pl.query_id =Qry.query_query_query AS .query_text_idwhere Qry.query_id=42481;

Fig. 11 Fråga-ID och plan-ID från DMV

Lite justering

Låt oss ta en titt på en annan fråga.

När vi kör frågan i Lista 6 och undersöker detaljerna från Query Store, visar exekveringsplanens detaljer att vi behöver ett index för att få 51 % förbättring.

Anteckning 6:Suboptimal fråga

SELECT TOP (1000) [OrderLineID] ,[OrderID] ,[StockItemID] ,[Description] ,[PackageTypeID] ,[Quantity] ,[UnitPrice] ,[TaxRate] ,[PickedQuantity] ,[PickingCompleted,BNarnstE] ] ,[LastEditedWhen] FRÅN [WideWorldImporters].[Sales].[OrderLines] där enhetspris> 1000 GO 2000

Fig. 12 Suboptimala frågedetaljer

Fig. 13 Suboptimal frågeexekveringsplan

När vi väl har skapat det rekommenderade indexet med hjälp av satsen i lista 7, får vi frågeoptimeraren att generera en ny exekveringsplan. I det här fallet förväntas den nya genomförandeplanen förbättra prestandan. Det finns dock fall där vissa ändringar kan orsaka försämrad prestanda, såsom betydande förändringar i datamängden som effektivt ogiltigförklarar statistik eller minskar antalet index och så vidare. Sådana frågor sägs ha gått tillbaka i prestanda och kan undersökas med rapporten Regressed Queries i Query Store.

Anteckning 7:Skapa index

ANVÄND [WideWorldImporters]GOCREATE ECKLUSTERED INDEX [Custom_IX_UnitPrice]PÅ [Försäljning].[OrderLines] ([UnitPrice])INKLUDERA([OrderLineID],[OrderID],[StockItemID],[Description],[PackageQuantity-ID],[PackageQuantity-ID] ],[TaxRate],[PickedQuantity],[PickingCompletedWhen],[LastEditedBy],[LastEditedWhen])GO

Fig. 14 Optimerad fråga (ändring i exekveringsplan)

Fig. 15 Optimerad fråga (två planer)

Fig. 16 Optimerad fråga (Force Plan)

När det finns flera planer för en fråga som visas i Fig. 14 och Fig. 16, kan vi säga till optimeraren att alltid använda en plan som vi väljer genom att klicka på knappen Force Plan. Detta var en lite tråkig uppgift i de tidigare versionerna av SQL Server.

Som du kan se i fig. 17 tillåter Query Store oss att jämföra de olika planerna som är kopplade till en fråga med hjälp av ett antal mätvärden.

Fig. 17 Jämföra genomförandeplaner

Återigen kan vi använda frågan i Lista 8 för att verifiera planerna som är kopplade till detta fråge-ID med hjälp av DMV. (Se fig. 11)

Anteckning 8:Planer associerade med fråga 42497

ANVÄND WideWorldImportersGOSELECT Txt.query_text_id, Txt.query_sql_text, Pl.plan_id, Qry.*FRÅN sys.query_store_plan AS PlJOIN sys.query_store_query AS Qry ON Pl.query_id =Qry.query_query_query AS .query_text_idwhere Qry.query_id=42497;

Utforska varianter

En annan användbar rapport som Query Store använder oss av är Queries With High Variation. Den här rapporten visar hur långt ifrån varandra de önskade mätvärdena är för en specifik fråga under en given period. Detta är mycket användbart för historisk analys av prestanda. Med hjälp av påståendena i Lista 9 genererar vi data som kan ge en bild av hur variationer skulle se ut. Stegen i proceduren skapar helt enkelt en liten tabell och infogar sedan poster med olika batchstorlekar.

Anteckning 9:Planer associerade med fråga 42497

använd WideWorldImportersgo-- Skapa en tabellskapa tabell tableone(ID int identitet(1000,1),FirstName varchar(30),LastName varchar(30),CountryCode char(2),HireDate datetime2 default getdate());-- Infoga poster i partier av olika storlekarsinsert i tableone-värden ('Kenneth','Igiri','NG',getdate());GO 10000insert into tableone-värden ('Kwame','Boateng','GH', getdate());GO 10insert into tableone-värden ('Philip','Onu','NG',getdate());GO 100000insert into tableone-värden ('Kwesi','Armah','GH', getdate());GO 100

Query Store visar oss detaljer som minimi- och maxvärden för dessa mätvärden för specifika exekveringsintervall för frågan vi är intresserade av. I det här exemplet ser vi att detta helt enkelt är ett resultat av antalet batcher per exekvering (observera att parametrar faktiskt används för att exekvera INSERT-satsen). I produktionen kan andra faktorer vara ansvariga för sådana variationer.

Fig. 18 Variationer i varaktighet

Fig. 19 Variation i logiska skrivningar

Fig. 20 Variation i fysiska avläsningar

Slutsats

I den här artikeln har vi granskat SQL Server 2016 Query Store GUI-miljön och några saker vi kan härleda angående prestandan för vår instans (med avseende på SQL) med Query Store. Det finns flera artiklar på Internet som visar ännu mer avancerade användningsfall och mycket djupare förklaringar av det interna. Den här artikeln bör vara till nytta för DBA:er på mellannivå som vill få ett försprång när det gäller att använda Query Store för utvärdering/justering av prestanda.

Referenser

Bästa tillvägagångssätt med Query Store
Cristiman, L. (2016) Query Store – Inställningar och gränser
Övervaka prestanda genom att använda Query Store
Query Store Catalog Views
Fråga lagrade procedurer
Query Store – Hur det fungerar och hur man använder det
Frågebutikens användningsscenarier
Van de Lar, E. (2016) SQL Server 2016 Query Store:Framtvinga exekveringsplaner med hjälp av Query Store

Användbart verktyg:

dbForge Query Builder för SQL Server – tillåter användare att snabbt och enkelt bygga komplexa SQL-frågor via ett intuitivt visuellt gränssnitt utan manuell kodskrivning.