Benjamin Nevarez är en oberoende konsult baserad i Los Angeles, Kalifornien, som specialiserat sig på justering och optimering av SQL Server-frågor. Han är författare till "SQL Server 2014 Query Tuning &Optimization" och "Inside the SQL Server Query Optimizer" och medförfattare till "SQL Server 2012 Internals". Med mer än 20 års erfarenhet av relationsdatabaser har Benjamin också varit föredragshållare vid många SQL Server-konferenser, inklusive PASS Summit, SQL Server Connections och SQLBits. Benjamins blogg finns på http://www.benjaminnevarez.com och han kan också nås via e-post på admin på benjaminnevarez dot com och på twitter på @BenjaminNevarez.
Har du någonsin hittat en planregression efter en SQL Server-uppgradering och velat veta vad den tidigare exekveringsplanen var? Har du någonsin haft problem med frågeprestanda på grund av att en fråga oväntat fick en ny exekveringsplan? Vid det senaste PASS-toppmötet upptäckte Conor Cunningham en ny SQL Server-funktion, som kan vara till hjälp för att lösa prestandaproblem relaterade till dessa och andra förändringar i exekveringsplaner.
Den här funktionen, som kallas Query Store, kan hjälpa dig med prestandaproblem relaterade till planändringar och kommer snart att finnas tillgänglig på SQL Azure och senare i nästa version av SQL Server. Även om det förväntas vara tillgängligt på Enterprise Edition av SQL Server, är det ännu inte känt om det kommer att finnas tillgängligt på Standard eller någon annan utgåva. För att förstå fördelarna med Query Store, låt mig prata kort om felsökningsprocessen för frågor.
Varför är en fråga långsam?
När du har upptäckt att ett prestandaproblem beror på att en fråga är långsam, är nästa steg att ta reda på varför. Uppenbarligen är inte alla problem relaterade till planändringar. Det kan finnas flera anledningar till att en fråga som har fungerat bra plötsligt är långsam. Ibland kan detta vara relaterat till blockering eller problem med andra systemresurser. Något annat kan ha förändrats men utmaningen kan vara att ta reda på vad. Många gånger har vi ingen baslinje om systemresursanvändning, exekveringsstatistik för frågor eller prestandahistorik. Och vanligtvis har vi ingen aning om vad den gamla planen var. Det kan vara så att någon förändring, till exempel data, schema eller frågeparametrar, fick frågeprocessorn att ta fram en ny plan.
Planera ändringar
Vid sessionen använde Conor verktyget Picasso Database Query Optimizer Visualizer, även om det inte nämndes vid namn, för att visa varför planerna i samma fråga ändrades, och förklarade det faktum att olika planer kunde väljas för samma fråga baserat på selektiviteten hos deras predikat. Han nämnde till och med att frågeoptimeringsteamet använder detta verktyg, som utvecklats av Indian Institute of Science. Ett exempel på visualiseringen (klicka för att förstora):
Picasso Database Query Optimizer Visualizer
Varje färg i diagrammet är en annan plan, och varje plan väljs utifrån predikatens selektivitet. Ett viktigt faktum är att när en gräns korsas i grafen och en annan plan väljs, bör kostnaden och prestandan för båda planerna oftast vara lika, eftersom selektiviteten eller det uppskattade antalet rader endast ändras något. Detta kan till exempel hända när en ny rad läggs till i en tabell som kvalificerar sig för det använda predikatet. Men i vissa fall, mestadels på grund av begränsningar i kostnadsmodellen för frågeoptimeraren där den inte kan modellera något korrekt, kan den nya planen ha en stor prestandaskillnad jämfört med den tidigare, vilket skapar problem för din applikation. Förresten, planerna som visas i diagrammet är den slutliga planen som valts av frågeoptimeraren, blanda inte ihop detta med de många alternativ som optimeraren måste överväga för att bara välja ett.
Ett viktigt faktum, enligt min åsikt, som Conor inte täckte direkt, var förändringen av planer på grund av regressioner efter ändringar av kumulativa uppdateringar (CUs), service packs eller versionsuppgraderingar. Ett stort problem som kommer att tänka på med ändringar i frågeoptimeraren är planregressioner. Rädslan för planregressioner har ansetts vara det största hindret för förbättringar av frågeoptimerare. Regressioner är problem som introduceras efter att en korrigering har tillämpats på frågeoptimeraren, och ibland hänvisas till som det klassiska "två eller fler fel gör ett rätt". Detta kan hända när till exempel två dåliga uppskattningar, en som överskattar ett värde och den andra som underskattar det, tar bort varandra, vilket lyckligtvis ger en bra uppskattning. Att korrigera endast ett av dessa värden kan nu leda till en dålig uppskattning som kan påverka valet av plan negativt och orsaka en regression.
Vad gör Query Store?
Conor nämnde att Query Store fungerar och kan hjälpa till med följande:
- Lagra historiken för frågeplaner i systemet;
- Fånga resultatet för varje frågeplan över tid;
- Identifiera frågor som "har blivit långsammare nyligen";
- Låt dig tvinga fram planer snabbt; och,
- Se till att detta fungerar över serverstarter, uppgraderingar och omkompilering av frågor.
Så den här funktionen lagrar inte bara planerna och relaterad frågeprestandainformation, utan kan också hjälpa dig att enkelt tvinga fram en gammal frågeplan, som i många fall kan lösa ett prestandaproblem.
Hur man använder Query Store
Du måste aktivera Query Store genom att använda ALTER DATABASE CURRENT SET QUERY_STORE = ON; påstående. Jag provade det i min nuvarande SQL Azure-prenumeration, men uttalandet returnerade ett fel eftersom det verkar som att funktionen inte är tillgänglig ännu. Jag kontaktade Conor och han berättade att funktionen snart kommer att finnas tillgänglig.
När frågebutiken är aktiverad börjar den samla in planerna och frågeprestandadata och du kan analysera denna data genom att titta på frågebutikstabellerna. Jag kan för närvarande se dessa tabeller på SQL Azure men eftersom jag inte kunde aktivera Query Store, returnerade katalogerna ingen data.
Du kan analysera informationen som samlas in antingen proaktivt för att förstå förändringarna i frågas prestanda i din applikation, eller retroaktivt om du har ett prestandaproblem. När du har identifierat problemet kan du använda traditionella frågejusteringstekniker för att försöka lösa problemet, eller så kan du använda sp_query_store_force_plan lagrad procedur för att tvinga fram en tidigare plan. Planen måste registreras i Query Store för att kunna framtvingas, vilket uppenbarligen betyder att det är en giltig plan (åtminstone när den samlades in, mer om det senare) och att den genererades av frågeoptimeraren tidigare. För att tvinga fram en plan behöver du plan_id , tillgänglig i sys.query_store_plan katalog. När du tittar på de olika mätvärdena som lagras, som är mycket lika det som lagras till exempel i sys.dm_exec_query_stats , kan du fatta beslutet att optimera för ett specifikt mått, som CPU, I/O, etc. Sedan kan du helt enkelt använda ett uttalande som det här:
EXEC sys.sp_query_store_force_plan @query_id = 1, @plan_id = 1;
Detta säger åt SQL Server att tvinga plan 1 på fråga 1. Tekniskt sett kan du göra samma sak med hjälp av en planguide, men det skulle vara mer komplicerat och du måste manuellt samla in och hitta den plan som krävs i första hand.
Hur fungerar Query Store?
Att tvinga fram en plan använder planguider i bakgrunden. Conor nämnde att "när du kompilerar en fråga lägger vi implicit till en ANVÄNDNINGSPLAN-tips med fragmentet av XML-planen som är associerad med det uttalandet." Så du behöver inte längre använda en planguide längre. Tänk också på att, precis som att använda en planguide, är det inte garanterat att ha exakt den påtvingade planen utan åtminstone något som liknar den. Ta en titt på den här artikeln för en påminnelse om hur planguider fungerar. Dessutom bör du vara medveten om att det finns vissa fall där framtvingande av en plan inte fungerar, ett typiskt exempel är när schemat har ändrats, det vill säga om en lagrad plan använder ett index men indexet inte längre finns. I det här fallet kan SQL Server inte tvinga planen, kommer att utföra en normal optimering och den kommer att registrera det faktum att framtvingandet av planen misslyckades i sys.query_store_plan katalog.
Arkitektur
Varje gång SQL Server kompilerar eller kör en fråga skickas ett meddelande till Query Store. Detta visas härnäst.
Översikt över Query Store Workflow
Kompilerings- och exekveringsinformationen hålls först i minnet och sparas sedan på disk, beroende på Query Store-konfigurationen (data sammanställs enligt INTERVAL_LENGTH_MINUTES parameter, som är standard på en timme, och rensas till disk enligt DATA_FLUSH_INTERVAL_SECONDS parameter). Data kan också spolas till disk om det är minnestryck på systemet. I vilket fall som helst kommer du att kunna komma åt all data, både i minnet och på disken, när du kör sys.query_store_runtime_stats katalog.
Kataloger
Den insamlade informationen finns kvar på disken och lagras i användardatabasen där Query Store är aktiverat (och inställningarna lagras i sys.database_query_store_options . Query Store-katalogerna är:
sys.query_store_query_text | Frågetextinformation |
sys.query_store_query | Frågetext plus den använda planen som påverkar SET-alternativen |
sys.query_store_plan | Utförandeplaner, inklusive historik |
sys.query_store_runtime_stats | Fråga körtidsstatistik |
sys.query_store_runtime_stats_interval | Start- och sluttid för intervaller |
sys.query_context_settings | Fråga information om kontextinställningar |
Query Store-vyer
Runtime-statistik fångar en hel rad mätvärden, inklusive genomsnitt, senaste, min, max och standardavvikelse. Här är hela uppsättningen kolumner för sys.query_store_runtime_stats :
runtime_stats_id | plan_id | runtime_stats_interval_id | ||
execution_type | execution_type_desc | first_execution_time | last_execution_time | count_executions |
avg_duration | last_duration | min_duration | max_duration | stdev_duration |
avg_cpu_time | last_cpu_time | min_cpu_time | max_cpu_time | stdev_cpu_time |
avg_logical_io_reads | last_logical_io_reads | min_logical_io_reads | max_logical_io_reads | stdev_logical_io_reads |
avg_logical_io_writes | last_logical_io_writes | min_logical_io_writes | max_logical_io_writes | stdev_logical_io_writes |
avg_physical_io_reads | last_physical_io_reads | min_physical_io_reads | max_physical_io_reads | stdev_physical_io_reads |
avg_clr_time | last_clr_time | min_clr_time | max_clr_time | stdev_clr_time |
avg_dop | last_dop | min_dop | max_dop | stdev_dop |
avg_query_max_used_memory | last_query_max_used_memory | min_query_max_used_memory | max_query_max_used_memory | stdev_query_max_used_memory |
avg_rowcount | last_rowcount | min_rowcount | max_rowcount | stdev_rowcount |
Kolumner i sys.query_store_runtime_stats
Denna data samlas bara in när exekveringen av en fråga slutar. Query Store tar också hänsyn till frågans SET alternativ, som kan påverka valet av en exekveringsplan, eftersom de påverkar saker som resultatet av att utvärdera konstanta uttryck under optimeringsprocessen. Jag tar upp det här ämnet i ett tidigare inlägg.
Slutsats
Detta kommer definitivt att vara en fantastisk funktion och något jag skulle vilja prova så snart som möjligt (förresten, Conors demo visar "SQL Server 15 CTP1" men de bitarna är inte offentligt tillgängliga). Query Store kan vara användbar för uppgraderingar som kan vara en CU, service pack eller SQL Server-version, eftersom du kan analysera informationen som samlas in av Query Store före och efter för att se om någon fråga har gått tillbaka. (Och om funktionen är tillgänglig i lägre upplagor kan du till och med göra detta i ett SKU-uppgraderingsscenario.) Att veta detta kan hjälpa dig att vidta några specifika åtgärder beroende på problemet, och en av dessa lösningar kan vara att tvinga fram den tidigare planen som förklarats tidigare.