Triangle SQL Server User Group Adaptive Query Processing with Azure SQL DB and SQL Server 2017

Transcription

1 Triangle SQL Server User Group Adaptive Query Processing with Azure SQL DB and SQL Server 2017 Joe Sack, Principal Program Manager, Microsoft

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

3 Adaptability In SQL server 2017 and Azure SQL Database

4 Adaptive Query Processing Feature Family

5 Example problem query

6 MSTVF definition

7 Function Types Scalar 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

8 MSTVF execution plan example

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

10 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

11 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

12 Interleaved Execution Optimize Pre 2017 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 MSTVF identified 100 rows guessed for MSTVFs Execute MSTVF Performance issues if skewed! 500k rows assumed Good Performance!

13 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

14 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

15 Demo: Adaptive query processing feature family

16 How to enable AQP features?

17 Speaking of 140 what else gets enabled with it? Trivial plans get disabled for Columnstore-referencing queries (allowing for batch execution mode) TRIVIAL FULL

18 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

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

20 About Interleaved Execution Expected performance improvements? Benefits workloads with skews and downstream operations A Original Exec Time (sec) Interleaved Execution Time (sec) B

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

22 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)

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

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

25 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 Adaptive Join Test Results Retail Top Products Report Customer Invoice Transactions Adaptive join enabled (seconds) Adaptive join disabled (seconds)

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

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

28 Cost Adaptive Join Threshold Adaptive Join Threshold 1 50,000 Rows Hash Join Nested Loop Join

29 The middle-ofthe-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

30 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? Queries SQL Database Query Store Deeper Insight

31 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 a regression is detected

32 Demo Automatic Tuning

33 Faster Cadence You can expect that we aren t returning to a slower release cycle What s next after SQL Server 2017? Customer driven Cloud Service Influenced Our choices will be very influenced by customer drivers both in SQL Server and Azure SQL Database 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 Adaptation While not every complexity can be addressed, we will look to minimize and mitigate through adaptive mechanisms (feedback loops, flexible compilation, adaptive switches based on runtime conditions)