Joe Sack, Principal Program Manager, Microsoft Joe.Sack@Microsoft.com SQLintersection Adaptive Query Processing with Azure SQL DB and SQL Server 2017 Joe Sack, Principal Program Manager, Microsoft Joe.Sack@Microsoft.com

SQL Server 2017 Themes Choice Mindshare Adaptability Adapt based on customer workload characteristics Adaptability Provide customers with a choice Choice Leverage the strength of strong technical communities Mindshare

Adaptability In SQL server 2017 and Azure SQL Database

The middle-of-the-night call There has been a jump in CPU utilization on a key server, and one of the critical stored procedure calls is now running (much) more slowly then it used to? You need to mitigate the issue and then determine the root cause

Query Store Comprehensive query-performance information when you need it most ‘Flight-data recorder’ for your database: Queries, plans, and compilation and runtime statistics available at your fingertips Allows you to easily identify and fix performance issues in the minutes Enables the following scenarios: Finding regressed queries Identifying top resource consuming queries Ad-hoc workload optimization Smooth application upgrades Query Store ? SQL Database Queries Deeper Insight Query Store provides comprehensive query performance information when you need it most.   By collecting and presenting detailed historic information about all queries, Query Store significantly reduces the time to diagnose and resolve performance issues.  If a query generates a different plan, you can use Query Store to analyze the query plan changes, possible performance degradation, or force the system to use a particular plan for your query. Lets you identify queries that used to perform well but are now performing poorly. Troubleshoot in minutes Find regressed queries Identify top resource-consuming queries Optimize workloads as needed Upgrade apps smoothly

SQL Server 2017: Automatic tuning We can now detect and correct these scenarios without manual intervention Recommended actions surfaced via sys.dm_db_tuning_recommendations We can now automatically switch to the last known good plan whenever the regression is detected

Demo Automatic Tuning

Adaptive Query Processing In SQL Server 2017 and Azure SQL Database

Adaptive Query Processing Feature Family

Example “problem” query

MSTVF definition

Function Types Scalar Function Multi-statement table-valued function Series of T-SQL statements that evaluate to a scalar value Multi-statement table-valued function Series of T-SQL statements that populate a TABLE return variable Inline table-valued function TABLE return value is defined via a single SELECT statement

MSTVF execution plan example

Query Processing and Cardinality Estimation When estimates are accurate (enough), we make informed decisions around order of operations and physical algorithm selection CE uses a combination of statistical techniques and assumptions During optimization, the cardinality estimation (CE) process is responsible for estimating the number of rows processed at each step in an execution plan

Common reasons for incorrect estimates Missing statistics Stale statistics Inadequate statistics sample rate Bad parameter sniffing scenarios Out-of-model query constructs E.g. MSTVFs, table variables, XQuery Assumptions not aligned with data being queried E.g. independence vs. correlation

Cost of incorrect estimates Slow query response time due to inefficient plans Excessive resource utilization (CPU, Memory, IO) Spills to disk Reduced throughput and concurrency T-SQL refactoring to work around off-model statements

Interleaved Execution Pre 2017 Optimize Execute Problem: Multi-statement table valued functions (MSTVFs) are treated as a black box by QP and we use a fixed optimization guess Interleaved Execution will materialize row counts for multi-statement table valued functions (MSTVFs) Downstream operations will benefit from the corrected MSTVF cardinality estimate 100 rows guessed for MSTVFs Performance issues if skewed! 2017+ MSTVF identified Execute MSTVF 500k rows assumed Good Performance!

Batch Mode Memory Grant Feedback Problem: Queries may spill to disk or take too much memory based on poor cardinality estimates MGF will adjust memory grants based on execution feedback MGF will remove spills and improve concurrency for repeating queries

Batch Mode Adaptive Joins Problem: If cardinality estimates are skewed, we may choose an inappropriate join algorithm AJ will defer the choice of hash join or nested loop until after the first join input has been scanned AJ uses nested loop for small inputs, hash joins for large inputs

Demo: Adaptive query processing feature family

How to enable AQP features?

Speaking of 140 – what else gets enabled with it? Trivial plans get disabled for Columnstore-referencing queries. 130 140 TRIVIAL FULL

Speaking of 140 – what else gets enabled with it? Predicates on LOB columns can use batch mode if there are Columnstore indexes being used within the query

Speaking of 140 – what else gets enabled with it? Batch mode for entire execution of external script

About Interleaved Execution Expected performance improvements? Benefits workloads with skews and downstream operations

About Interleaved Execution Minimal, since we’re already materializing MSTVFs Expected overhead? First execution cached will be used by consecutive executions Cached plan considerations Contains Interleaved Execution Candidates Is Interleaved Executed Plan attributes Execution status, CE update, disabled reason Xevents

Interleaved Execution Candidates SELECT statements 140 compatibility level MSTVF not used on the inside of a CROSS APPLY Not using plan forcing Not using USE HINT with DISABLE_PARAMETER_SNIFFING (or TF 4136)

About Batch Mode Memory Grant Feedback Benefits workloads with spills or overages Expected performance improvements? Before After

About Batch Mode Memory Grant Feedback If there is oscillation, we will disable the loop Expected overhead? Spill report, and updates by feedback Xevents For spills – spill size plus a buffer. For overages – reduce based on waste, and add a buffer. Expected decrease and increase size? Memory grant size will go back to original. RECOMPILE or eviction scenarios

About Batch Mode Adaptive Join Expected performance benefit? Performance gains occur for workloads where, prior to adaptive joins being available, the optimizer chooses the wrong join type due to cardinality misestimates

About Batch Mode Adaptive Join We grant memory even for NL scenario, so if NL is * always * optimal, you have more overhead Expected overhead? Adaptive Threshold Rows, Estimated and Actual Join Type Plan attributes Adaptive join skipped Xevents Single compiled plan can accommodate low and high row scenarios Cached plan considerations

About Batch Mode Adaptive Join Eligible statements The join is eligible to be executed both by an indexed nested loop join or a hash join physical algorithm The hash join uses batch mode – either through the presence of a Columnstore index in the query overall or a Columnstore indexed table being referenced directly by the join The generated alternative solutions of the nested loop join and hash join should have the same first child (outer reference)

Adaptive Join Threshold

What’s next after SQL Server 2017? You can expect that we aren’t returning to a slower release cycle Faster Cadence Our choices will be very influenced by customer drivers both in SQL Server and Azure SQL Database Customer driven Azure SQL DB service best practices will continue to flow into SQL Server – what we fix in the service, we’ll want to port to SQL Server as well Cloud Service Influenced While not every complexity can be addressed, we will look to minimize and mitigate through adaptive mechanisms (feedback loops, sampling, adaptive switches based on runtime conditions) Adaptation AI @ Microsoft: Engineering the Future by Matthew Johnson up next

Questions? Don’t forget to complete an online evaluation! Adaptive Query Processing with Azure SQL DB and SQL Server vNext Your evaluation helps organizers build better conferences and helps speakers improve their sessions. Thank you!

Save the Date www.SQLintersection.com Oct 30-Nov 2, 2017 We’re back in Vegas baby!