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

2. DBA challenges

3. 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 ?

4. 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;

5. 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

6. 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 =  #abc  #G123
SELECT * FROM Table WHERE col_a = 1  #bcd  #G123

7. 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”

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

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

10. 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

11. 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

12. Demo Query with Multiple Plans
USE either one:
Query Data Store Compatibility Level SP. SQL
Query Data Store Compatibility Level – DynamicSQL.SQL

13. 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
= N'getAddresses‘
-- change to actual plan handle from cache
= 0x AB3472DC082D1ECA …
-- change this to the actual offset from cache
= 142

14. 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
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 = 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
= N'OBJECT'
= N'Sales.GetSalesOrderByCountry'
= NULL
= N'OPTION (OPTIMIZE FOR = 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';

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

16. 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

17. Query Store Defined

18. 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

19. 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

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

21. Using Query Store
Insight on queries with Regressed performance

22. Using Query Store
Insight on Resource Consumption

23. Using Query Store
Insight on Top Resource Consumers

24. Using Query Store
Insight on Tracked Queries

25. Query Store Internals

26. 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

27. 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

28. 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)

29. 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

30. 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

31. 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

32. Demo Using Query Store

33. 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