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

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

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

4. Agenda
Background
Architecture
Configuration
Usage

5. Background

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

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

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

9. Picasso Database Query Optimizer Visualizer

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

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

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

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

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

15. Architecture

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

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

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

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

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

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

22. 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]
views/sys-query-store-wait-stats-transact-sql

23. Configuration

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

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

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

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

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

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

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

31. Usage

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

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

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

35. SQL Server Management Studio

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

37. Detect Different Plans

38. Compare Different Plans

39. Force Plan

40. Confirm forced plan

41. Questions