1. Inside the SQL Server Query Store
SQL Saturday OKC 2016 Edition
Inside the SQL Server Query Store
Want deck and demos now?
Bob Ward
Principal Architect – Tiger Team
Microsoft
@bobwardms
Credits to Jack Li, Conor Cunningham, and the entire QDS team

2. Objectives and Takeaways
Understand What is the Query Store and Why it can be useful for Query Performance
Understood How the Query Store works to know its capabilities and limitations
Understand how to troubleshoot problems that may occur while using the Query Store
A rich persisted database of query execution over time for SQL Server and Azure
It is the central starting point for Query Performance Tuning and Troubleshooting

3. Just Do It!
Instructions in readme.txt in demo1_justdoit

4. The docs are very good. Start here
Where do we go next?
The docs are very good. Start here
The What and the Why
What is tracked and persisted
How does it really work?
How do I manage it and what if doesn’t work?
In-Memory OLTP and Azure SQL Database

5. The What and the Why A store of compiled queries, plans, and stats
It is a database (store) of query history made up of memory structures and system tables
Contains statements, plans, properties, and statistics
A Query Flight Recorder
Why is it useful
Analyze performance and details of cacheable queries and plans that are no longer in cache
Analyze the history of queries and plans across server restarts
Look at properties and statistics for queries not available in DMVs
Allows a simpler method to force plans vs using plan guides
Survives crashes
Records critical information
Records for limited time
Doesn’t record everything

6. What can you do with this?
Use the scenarios page
What can you do with this?
Plan regression
Analyze and fix queries with plans changes over time
What queries consume the most/least cpu, i/o, memory over time?
Compare performance before/after a change (A/B Testing)
Plan stability after upgrading to SQL Server 2016
Are ad-hoc queries killing performance filling up your cache?
What is the standard deviation of performance for a query?
What % of time is the performance of my query spent on compile?
What is the performance of queries with different set_options?
Keep performance information in the backup of the database
Force a plan based on historical performance using a simple id

7. What is tracked and persisted
Plan store
Runtime stats
What is tracked and persisted
Persistence is async
Text of the SQL statement for the query
query_store_query_text
query_store_query
plan_persist_query_text
All query plans associated with a given statement/setting combo
plan_persist_query
query_store_context_settings
query_store_plan
plan_persist_context_settings
Aggregated stats for a plan in a specific time interval
plan_persist_plan
“settings” used for execution of the query
plan_persist_runtime_stats
query_store_runtime_stats_interval
query_store_runtime_stats
Start and end of time interval
plan_persist_runtime_stats_interval

8. In Out What is Tracked Query? Any T-SQL DML statement
WITH RECOMPILE
Ad-hoc even with ‘optimize’ set
Internal queries (auto stats)
Exceptions:
SET SHOWPLAN*
Queries executed from different db context
Any T-SQL DML statement
Independent of what is cached
Each statement in an object is a query
Statement text appears in parameterized form
CAPTURE_MODE can change this
Stored Procedure, Function, Trigger
Including cursors, SET assignment, and internal queries In
SELECT
UPDATE
INSERT
DELETE
Out
DDL
BULK INSERT
“Commands”
CREATE, ALTER, DROP, …
DBCC, KILL, BACKUP, …
Characters inside the statement matter

9. Query Store and Statistics
All datetime values are UTC
calculated
Execution
Timestamp – first and last
Count
Duration – min, max, last, total, avg, stdev
CPU – min, max, last, total, avg, stdev
Logical I/O (read and writes) – min, max, last, total, avg, stdev
Physical Reads – min, max, last, total, avg, stdev
CLR – min, max, last, total, avg, stdev
DOP – min, max, last, total, avg, stdev
Query Memory Used – min, max, last, total, avg, stdev
Rowcount – min, max, last, total, avg, stdev
Compilation
Timestamp – first and last
Count
Duration – total, avg, last
Bind (CPU and Duration) – total, avg, last
Optimize (CPU and Duration) – total, avg, last
Memory – total, avg, and max
microseconds
both calculated
parse
All of these at query level. Some at plan level
The Power of the query store are statistics
Aggregated at interval level (default 60 mins)
Plan Store
Runtime Stats Store

10. One row for each unique combo for all queries
What else should I know?
“Config Settings” – sys.query_context_settings
set_options
cursor_options
schema_id
DMVs vs Query Store
compilation statistics
plan properties including engine version and db compat level
details and stats for plan variations used for a query over time
stdev sumsquare for execution stats stored
Recorded as queries are compiled
No polling required to “save off” or determine diffs
Record query execution stats even if aborted
Go here to interpret bitmask
Aborted = client (timeout)
Exception = Server Error

11. Exploring the Query Store
Instructions in readme.txt in demo2_exploreqds

12. The query store architecture
Disclaimer: Some of the following details are subject to change and may not be documented
This picture from docs but we are going to explorer deeper. Then I’ll do some demos to make it real
Let’s talk Execution Flow, Memory Structure, Background Tasks, and other facts on “how it works”
qds.dll

13. Compiling and the Plan Store
if in cache, only execution stats updated
query_text
Statement Not in Store
If context does not exist
Statement In Store
Update compile
stats
context_settings
If context does not exist
Statement in Store with New Context
query
Update compile
Stats or new plan
Update compile stats
query_plan
Statement in Store with New Plan

14. Execution and Runtime Stats
Stats Interval
Timeframe for aggregation of stats for plan
Flush Interval
How often we persist to disk
runtime_stats
insert exec stats
Plan in store executed for new interval
runtime_stats tables
“start” a new stats interval = Default 60 mins
runtime_stats_interval
update exec stats
Async persist to tables on
flush interval = Default 15mins
Plan in store executed in same interval
As we will see on the next slide, we actually can persist both plan store table data and runtime stats table data more often than 15 mins
update last execution time
plan store tables
plan store
update last execution time

15. How does persist work? Query Compilation from Worker Async queue
sp_query_store_flush_db = persist “now”
A steady rate to persist to tables
Query Compilation from Worker
Async queue
Plan store tables
Background Task (QDS_ASYNC_QUEUE)
Keep executing
Query Execution from Worker
Background Task
“Persist Query Store”
Keep executing
Background Task
“Persist Query Store”
command like '%QUERY STORE%'
DATA_FLUSH_INTERVAL_SECONDS
(Default 15 mins)
We are always adding to the queue for plan store and runtime stats. But there is no guarantee when this data will be persisted. The ONLY deterministic way to guarantee a flush is to use sp_query_store_flush_db. We do flush anything outstanding very 15 mins but if it takes longer to flush than that interval it may not always be every 15 minutes.
Runtime Stats
Tables
Background Task
“Sized Based Cleanup”
Background Task (QDS_PERSIST_TASK_MAIN_LOOP_SLEEP)
60secs
Other examples are
Time based cleanup or change back to read-write

16. Query Store Memory Structures
Memory Clerk/Object
Description
MEMORYCLERK_QUERYDISKSTORE_HASHMAP
Hash table of queries and plans for instance/node
Largest memory consumer
Uses MEMOBJ_QUERYDISKSTORE (NUMA enabled)
Repopulated from disk at startup
MEMORYCLERK_QUERYDISKSTORE
General clerk for overall Query Store for instance
Should be fairly fixed in size and small
MEMOBJ_QUERYSTOREPARTITIONEDHEAP
CPU partitioned heap for execution stats for instance
USERSTORE_QDSSTMT
Temp buffers to store statements before persisted
CACHESTORE_QDSCONTEXTSETTINGS
Track unique context settings across all queries
CACHESTORE_QDSRUNTIMESTATS
Cache of aggregated runtime stats before persisted
Per db. Created even if QDS not enabled
Per db. Created when QDS first used

17. Query Store Maintenance
sys.database_query_store_options
readonly_reason
Enabling, Clearing, and State
ON = Enable; OFF = Disabled (default, existing state and data kept); CLEAR = TRUNCATE tables
READ_WRITE = Default when ON; READ_ONLY = intentional or problem (desired != actual)
Size, limits, and retention
Default max size = 100Mb (limited by overall database size). If you hit max, state = READ_ONLY
Default max plans per query = 200 (this is silent but its well…200!)
Default days queries kept in store = 30 days
Capture and cleanup efficiently
Query capture mode of AUTO (Default is ALL) = capture relevant queries based on execution count and resource consumption. NONE = Stop capture new queries but track and persist stats for existing.
Sized based cleanup of AUTO (Default is AUTO) = Remove oldest queries and least expensive when 90% of max (until 80% reached). Overrides time retention (days kept in store)
sp_query_store_remove_plan = delete specific plan and associated runtime stats
sp_query_store_remove_query = delete query, associated query text, plans and runtime stats
sp_query_store_reset_exec_stats = Delete runtime stats for specific plan
Query Store Best Practices well documented
XEvent to trace

18. Facts You Should Know
Non EE/Dev edition have auto cleanup issue
Query plan garbled? Get plan_id and then get XML plan. Working on a fix
Queries are only tracked if in enabled db context
Use ALTER to modify objects or “duplicate” queries will be tracked
Forcing plans is better than Plan Guides
Force by a simple id
You can change the text of a procedure
There is a cost (ad-hoc and In-Memory workloads)
stmt_sql_handle matches statement not batch
Join with dm_exec_query_stats
Efficient index for query_store_query_text
Find handle from text (even for parameterized queries)
Encrypted procs hides text as with DMVs or catalog views
We have seen negligible impact from using Query Store with TPC
Consider Query Mode Capture = AUTO

19. Query Store Troubleshooting
Query store reverts to read-only mode
Database not in state to allow writing (emergency, read-only, single user, …)
Max storage size hit
Memory limits (Azure SQL Database only)
Failure forcing plans
Query still compiles and executes
Unforcing a plan clears previous force fail reason
You must remove the failed force plan to allow new plan to be stored
Restore backup considerations
Set to READ_ONLY if using for analysis
If you restore to a different database name forced plans may fail
Tracing and Monitoring
XEvent : 60+ events named query_store*
Perfmon: SQL Server: Query Store
Index no longer exists, Rename database, ….

20. Let’s Look Inside
Instructions in readme.txt in demo3_insideqds

21. Query Store and In-Memory OLTP
See details here
Query Store and In-Memory OLTP
Enabled != Runtime Stats enabled for native procs
sp_xtp_control_query_exec_stats – specific natively compiled procedure
sp_xtp_control_proc_exec_stats – all natively compiled procedures in database
Recompile proc if Query Store enabled after compile or you clear store or remove query/plan
Statistics and Properties
Use is_natively_compiled from query_store_plan to identify natively compiled procedures
Compilation duration does not include time spent in C code compilation/generation
Other Facts
Forcing plans works as with regular queries
Query capture mode does not affect natively compiled procedures (it is always ALL)
Memory grant metrics not captured for natively compiled procedures
sp_recompile

22. Query Store and Azure SQL Database
Functionality and Capability identical
Catalog Views all available
Query Store in database aligned with Azure “contained” concept
Available for all service tiers
SSMS Reports Supported
Differences
ON by default
Query capture = AUTO;
We do limit memory for Query Store and may revert to read-only mode memory overcommitted
You may need to upgrade to a higher service tier
Powers other Functionality
Query Performance Insight
SQL Database Advisor
Query Performance Insight – Visual representation of Query Store to look at DTU performance
SQL Database Advisor – Use Query Store to make index recommendations and then back off if negative impact. Also now supports recommendations for schema issues or parameterized queries

23. Power BI and Query Store

24. Resources Query Store team blog post
Query Store: A flight data recorder for your database
Feature documentation
Query store default settings

26. Share your selfie with hashtag #SSGAS2016 and win cool prizes
Connect us with us:
@SQLServerGeeks
facebook.com/SQLServerGeeks
facebook.com/groups/theSQLGeeks