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

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

3. Adaptability
In SQL server 2017 and Azure SQL Database

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

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

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

7. Demo Automatic Tuning

8. Adaptive Query Processing
In SQL Server 2017 and Azure SQL Database

9. Adaptive Query Processing Feature Family

10. Example “problem” query

11. MSTVF definition

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

13. MSTVF execution plan example

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

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

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

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

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

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

20. Demo: Adaptive query processing feature family

21. How to enable AQP features?

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

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

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

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

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

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

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

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

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

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

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

33. Adaptive Join Threshold

34. 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
Microsoft: Engineering the Future by Matthew Johnson up next

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

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