Query Store: Making Sure Your Database Queries Run Optimally Victor Isakov Microsoft Certified Architect Bespoke SQL

Victor Isakov Victor Isakov is a Database Architect / Trainer / Author who provides consulting and training services to various organizations in the public, private and NGO sectors globally. He participates in different capacities at various international events and conferences. One of only 3 non-Microsoft Microsoft Certified Architects globally Designing SQL Server infrastructure solutions and upgrade strategies Architecting OLTP, DSS and DW database solutions Performance troubleshooting and optimization Customized on premise training and mentoring

Abstract Fixing performance problems and detecting query regressions has never been easy in SQL Server as the database engine fundamentally does not capture the relevant information. With the release of SQL Server 2016, Microsoft has introduced a feature called Query Store that will help you capture vital query metrics that will help performance troubleshooting and regression detection. In this session we will examine Query Store and how it can be used in a myriad of use cases. We will examine its architecture, configuration and shortcomings. This session will help you build a monitoring solution that will help you detect and solve real-world performance problems across your entire SQL Server infrastructure. It will also substantially help de-risk upgrade projects, so there's no "excuse" not to upgrade to SQL Server 2016/2017!

Agenda Background Architecture Configuration Usage

Background

Introduction Long time coming… Difficulty facing DBAs Easily identify top resource consumers within the database De-risk Upgrade Projects Better analyze query execution Historically compare query execution Easily find and fix query regressions

Query Regression What is query regression? How can we detect query regression?

Fixing Plan Regression is Difficult So you find a query is slow… Why is it slow? Lack of resources Poor indexing Blocking Plan change What was the plan before? If you knew that would help Plan hint Plan guide?

Picasso Database Query Optimizer Visualizer http://dsl.serc.iisc.ernet.in/projects/PICASSO/

Why Plans Change Query Optimiser considers many plans Data changes can lead to different plans As “boundary” is crossed performance should be ideally “similar” Data Cardinality Sometimes performance is drastically different

Cardinality Estimator 2.0 Introduced in SQL Server 2014 Internal “stuff” Microsoft has not touched since SQL Server 7.0 Architecture is showing it’s age… Improved cardinality estimation Upgrading to SQL Server 2014/2016 probably has a “higher” risk with query performance regression than in previous versions

Microsoft’s Design Goals Store history of plans for each query Capture performance of each plan over time Identify queries that have gotten slower recently Allow you to force plans easily Better story than current plan guide implementation Make sure this works across server restarts, upgrades and query recompiles Minimal impact on query performance SQL Server 2016 represents v.1 “Enhanced” in SQL Server 2017

Upgrades, Failovers & Recompiles Query Store Usage Plan Recompiles Server Restarting Plan changes due to upgrade Reduce Risk with Upgrades Restore PROD backup to Proof-of-Concept server In-place Upgrades Run test workload Use Query Store to detect query regressions

Keep 110/120 Compatibility Level De-Risk Upgrades Take advantage of Query Store to de-risk database upgrades Can change on the fly without having to restart Database Engine Upgrade to SQL 2016 Keep 110/120 Compatibility Level Enable Query Store (Baseline) Change to 130 Compat Level Monitor Fix regressions (With plan forcing)

Architecture

Capturing Metrics/telemetry Events Generated by Workload Query Store captures in-memory Writes are queued in-memory Flushed to disk asynchronously DATA_FLUSH_INTERVAL_MINUTES Implications Minimize performance (I/O) overhead Can lose capture data Performance overhead: < 3%

Querying Consistent, unified view Querying Query Store merges in-memory and on-disk data Minimal delay Performance will be slightly slower than querying DMVs TVF In-Memory Data On-Disk Data

Schema Simple schema Primarily focussed on query execution  What’s missing?

[sys].[query_store_query_text] What is a query? [query_sql_text] Start at first character of first token End at last character of last token Comments before/after do not count Spaces inside count Comments inside count [statement_sql_handle] is a MD5 hast of query text

Query “Identification” Considerations Stored Procedures / UDFs / Triggers Query is scoped to containing object object_id of containing object is captured Useful, as can now query per stored procedure Aggregate Temporary Tables Scoped by the [batch_sql_handle] Not perfect Better story with Parameterized Queries

Metrics Captured Query Text Query Plan Runtime Statistics Per unit of time Default is 1 hour Metrics are captured when the query finishes executing Measures Duration, cpu_time, logical_io_reads, logical_io_writes, physical_io_reads, clr_time, DOP, query_max_used_memory, rowcount, etc Aggregates average, min, max, last, stddev

SQL Server 2017 Query Store now tracks wait stats summary information Addresses v.1 “limitation” of SQL Server 2016 “Tracking wait stats categories per query in Query Store enables the next level of performance troubleshooting experience, providing, even more, insight into the workload performance and its bottlenecks while preserving the key Query Store advantages.” [sys].[query_store_wait_stats] https://docs.microsoft.com/en-us/sql/relational-databases/system-catalog- views/sys-query-store-wait-stats-transact-sql

Configuration

Configuration Operation Mode Data Flush Interval Read Write | Read Data Flush Interval Statistics Collection Interval Default is 1 hour Maximum Size Capture Mode Size Based Cleanup Mode Stale Query Threshold

Capture Mode ALL Analyze your workload thoroughly in terms of all queries shapes and their execution frequencies and other statistics Identify new queries in your workload Detect if ad-hoc queries are used to identify opportunities for user or auto parameterization AUTO Focus your attention on relevant and actionable queries Queries that execute regularly or that have significant resource consumption Note: AUTO will automatically filter out ad-hoc queries with small resource consumption

Size Based Cleanup Mode Specifies whether automatic data cleanup will take place when Query Store data size approaches the limit Strongly recommended to activate size-based cleanup to ensure that: Query Store always runs in read-write mode Collects the latest data

Stale Query Threshold (Days) Time-based cleanup policy that controls the retention period of persisted runtime statistics and inactive queries By default, Query Store is configured to keep the data for 367 days which may be unnecessarily long for your scenario

Best Practices Keep the Most Relevant Data in Query Store Limit retained historical data Configure time-based policy to activate auto-cleanup Filter out non-relevant queries Configure Query Capture Mode to Auto Delete less relevant queries when maximum size is reached Activate size-based cleanup policy

Best Practices Avoid Using Non-Parameterized Queries Query Store can rapidly exceed the size quota because of potentially a large number of different query texts and consequently a large number of different execution plans with similar shape Parameterize queries where applicable, for example wrap queries inside a stored procedure Use the Optimize for Ad Hoc Workloads option if your workload contains many single use ad-hoc batches with different query plans Apply FORCED PARAMETERIZATION, for the database or for a subset of queries if the number of different query plans is not large Set the Query Capture Mode to AUTO to automatically filter out ad-hoc queries with small resource consumption

Best Practices Avoid a DROP and CREATE Pattern When Maintaining Containing Objects for the Queries Check the Status of Forced Plans Regularly Configure appropriate size limits Stop or overwrite Determine strategy for archival of metrics / telemetry Move records to “data warehouse”

Usage

Pre-Canned Reports Regressed Queries Overall Resource Consumption Pinpoint queries for which execution metrics have recently regressed Use this view to correlate observed performance problems in your application with the actual queries that needs to be fixed or improved Overall Resource Consumption Choose an execution metric of interest and identify queries that had the most extreme values for a provided time interval Use to focus your attention on the most relevant queries which have the biggest impact to database resource consumption

Pre-Canned Reports Top Resource Consuming Queries Tracked Queries Track the execution of the most important queries in real-time Typically, use when you have queries with forced plans and you want to ensure query performance is stable Tracked Queries Analyze the total resource consumption for the database for any of the execution metrics Use to identify resource patterns (night versus day) and optimize overall consumption for your database

Custom Reports Write your own queries Correlate with other information Telemetry/metrics that you can collect

SQL Server Management Studio

Force Plan If the query was executed with multiple plans and the last plan is significantly worse than previous plan You can use the plan forcing mechanism to force SQL Server to always use the optimal plan for future executions

Detect Different Plans

Compare Different Plans

Force Plan

Confirm forced plan

Questions victor@BespokeSQL.com.au www.linkedin.com/in/VictorIsakov