Inside the SQL Server Query Store SQL Saturday OKC 2016 Edition Inside the SQL Server Query Store Want deck and demos now? http://aka.ms/bobwardms http://aka.ms/bobsql Bob Ward Principal Architect – Tiger Team Microsoft bobward@microsoft.com @bobwardms http://aka.ms/bobsql Credits to Jack Li, Conor Cunningham, and the entire QDS team

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

Just Do It! Instructions in readme.txt in demo1_justdoit

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

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

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

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

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

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

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

Exploring the Query Store Instructions in readme.txt in demo2_exploreqds

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

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

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

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

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

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

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

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, ….

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

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

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

Power BI and Query Store

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

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