Twitter handle: @sammesel Sr. SQL Premier Field Engineer sam.mesel@microsoft.com Twitter handle: @sammesel LinkedIn: sam mesel Query Store

DBA challenges

Situations Available tools: CPU spikes Memory Queries taking longer to run Disk contention DMVs Profiler Trace Extended Events PSSDIAG / SQLNexus 3rd Party tools Anyone still using Profiler Trace ?

Using DMVs to investigate /* The query below returns the Top Cumulative CPU within last 1hour */ SELECT last_execution_time, total_worker_time AS [Total CPU Time], execution_count, total_worker_time / execution_count AS [Avg CPU Time], text, qp.query_plan FROM sys.dm_exec_query_stats AS qs CROSS APPLY sys.dm_exec_sql_text (qs.sql_handle) AS st CROSS APPLY sys.dm_exec_query_plan (qs.plan_handle) AS qp WHERE DATEDIFF(hour, last_execution_time, getdate()) < 1 ORDER BY total_worker_time DESC;

Other DBA activities Find queries that are executed the most ? Nothing else to do? Other DBA activities Find queries that are executed the most ? Optimizations on queries that run 1,000s of times will lead to big gains

Compile and Optimize Query Query Execution Check for Recompile Compile and Optimize Query Fetch Plan from Cache Plan Cache lookup Execute Query Finish Execution Query Execution Found Not found Not needed Recompile Convert TSQL statement into a handle. Uses this handle to search the cache select * from table where col_a = 1  #abc SELECT * FROM Table WHERE col_a = 1  #bcd 2) Normalized TSQL get a QUERY-HASH select * from table where col_a = 1  #abc  #G123 SELECT * FROM Table WHERE col_a = 1  #bcd  #G123

more DBA activities Find queries that have multiple Execution Plans? Nothing else to do? more DBA activities Find queries that have multiple Execution Plans? Use “Query Fingerprinting” and “Plan Fingerprinting” https://blogs.msdn.microsoft.com/bartd/2008/09/03/query-fingerprints-and-plan-fingerprints-the-best-sql-2008-feature-that-youve-never-heard-of/

More advanced DBAs Find queries that regressed over time ? Still bored? Find queries that regressed over time ? This requires more elaborated solutions

Demo using basic DMVs to investigate Query Cache Contents Start [initialdemo.cmd] Open queries: [QUery Data Store - 000 Using Basic DMVs to investigate Query Cache.sql]

Possible Complications Solutions: Query is no longer in cache ? Can the server be so busy that it flushes out queries from query cache ? Would it be the case my server has too little memory ? Was SQL Server restarted ? Has the DBA flushed the cache? Frequent DMV collections

Possible Complications (2) Solutions With new plan we can get better or worse performance Why does execution plan change ? SQL Server Query Optimizer performs calculations to decide amongst several Execution plans, which one will be “good enough” for your query. Once a plan is chosen, it will be placed in the query cache As data changes, the query optimizer might select a different plan As the schema changes, there will be different options for the query optimizer to consider Plan Guide Limited to 8KB of query plan text (XML) Plan Freezing

Demo Query with Multiple Plans USE either one: Query Data Store - 008 - Compatibility Level 110 130 - SP. SQL Query Data Store - 009 - Compatibility Level 110 130 – DynamicSQL.SQL

Plan Freezing -- first, get the plan that is cached: SELECT s.plan_handle, s.statement_start_offset, t.text FROM sys.dm_exec_query_stats AS s CROSS APPLY sys.dm_exec_sql_text (s.sql_handle) AS t; -- now use the plan handle, and statement start offset from the line that begins -- with query text pattern -- for the next step this step freezes the plan in cache: EXECUTE sp_create_plan_guide_from_handle @name = N'getAddresses‘ -- change to actual plan handle from cache ,@plan_handle = 0x050007009AB3472DC082D1ECA10100000100000000… -- change this to the actual offset from cache ,@statement_start_offset = 142

Plan Guide CREATE PROCEDURE Sales.GetSalesOrderByCountry @Country NVARCHAR (60) AS BEGIN SELECT * FROM Sales.SalesOrderHeader AS h, Sales.Customer AS c, Sales.SalesTerritory AS t WHERE h.CustomerID = c.CustomerID AND c.TerritoryID = t.TerritoryID AND CountryRegionCode = @Country; END GO -- Run the stored proc and examine the query plan EXECUTE Sales.GetSalesOrderByCountry 'UK'; -- Next, create the plan guide and then rerun the test EXECUTE sp_create_plan_guide @name = N'PlanGuide_OptimizeForUS', @stmt = N' SELECT * FROM Sales.SalesOrderHeader AS h, Sales.Customer AS c, Sales.SalesTerritory AS t WHERE h.CustomerID = c.CustomerID AND c.TerritoryID = t.TerritoryID AND CountryRegionCode = @Country;' , @type = N'OBJECT' , @module_or_batch = N'Sales.GetSalesOrderByCountry' , @params = NULL , @hints = N'OPTION (OPTIMIZE FOR (@Country = N''US''))'; GO -- Run the stored proc and examine the query plan -- Did the plan change? Did it use the plan guide? EXECUTE Sales.GetSalesOrderByCountry 'UK';

“A Bad Plan is not the one which failed, but the one which succeeded at the Greatest Cost.” ~Anonymous DBA

What can the DBA do? Welcome to QUERY STORE Content 2 Creates custom solution storing Query and Plan history Baseline performance for each plan over time Identify queries that became slower Optimize those queries OR alternatively force a good known plan Test solution: Instance restarts query recompiles upgrades Welcome to QUERY STORE Content 2

Query Store Defined

What is Query Store? A repository created on a database basis that collects Queries and corresponding Execution plans Runtime statistics Ready to run visualizations on SSMS Regressed Queries Analysis by Resource Consumption Tracked Queries

What does it do for the DBA? Quickly find query plan with performance regression Easily fix plans by forcing previous plans Provides statistics of Queries executed on last X hours

Using Query Store Resource provides DBA with insight on queries and resource consumption

Using Query Store Insight on queries with Regressed performance

Using Query Store Insight on Resource Consumption

Using Query Store Insight on Top Resource Consumers

Using Query Store Insight on Tracked Queries

Query Store Internals

Query Execution Data is persisted to disk asynchronously in the background Query Execution Check for Recompile Compile and Optimize Query Fetch Plan from Cache Plan Cache lookup Execute Query Finish Execution Query Execution Found Not found Not needed Recompile Get forced plan Query Store Send text and plan Send execution stats

Using Query Store Collects query texts and all relevant properties Stores all plan choices and performance metrics Works across restarts / upgrades / recompiles Compile MSG Execute MSG Query Store Durability latency controlled by DB option DATA_FLUSH_INTERNAL_SECONDS Async Write-Back Compile Execute SQL Plan Store Runtime Stats Query Store Schema

Runtime Stats Interval Query Store schema internal tables exposed views Query Text Query Plan Runtime Stats sys. 1 - n 1 - n Compile stats: query_store_query_text query_context_settings query_store_query query_store_plan Context Settings Runtime Stats Interval Runtime stats: query_store_runtime_stats_interval query_store_runtime_stats One Row Per Query Text Per Plan Affecting Option (example: ANSI NULLS on/off) One Row Per Plan (for each query) One Row Per Plan Per Time Interval (example: 5 min)

Query Store details Plans and execution data are stored in the user database Query store data persists reboots, upgrades, restores etc. Plans and statistics are tracked at the database level Query Store is configurable Settings such as MAX_SIZE_MB, QUERY_CAPTURE_MODE, CLEANUP_POLICY allow you to decide how much data you want to store for how long Can be configured either via the SSMS GUI or T-SQL scripts Query Store can be viewed and managed via scripting or SSMS

What does Query Store track? Query Texts start at the first character of the first token of the statement; end at last character of last token Comments before/after do not count Spaces and comments inside *do* count Context_settings contains one row per unique combination of plan-affecting settings Different SET options cause multiple “queries” in the Query Store Plan caching/recompilation behavior unaffected

What gets captured ? Query Texts Query Plans Runtime Statistics (per unit of time, default 1 hour) Count of executions of each captured plan For each metric: average, last, min, max, stddev Duration CPU_Time CLR_Time Logical_IO_Reads Logical_IO_Writes Physical_IO_Reads DOP Query_max_use_memory RowCount

Demo Using Query Store

Short-term / Tactical Long-Term / Strategic Scenarios Find and fix query plan regressions Identify top resource consumers Reduce risks with server upgrade Deep analysis of workload patterns/perf Short-term / Tactical Long-Term / Strategic