Performance Tuning with Execution Plans
3 likes778 views
The document covers performance tuning using execution plans in SQL Server, emphasizing the understanding of where and why performance issues occur. It includes discussions on evaluating execution plans, identifying common T-SQL code smells, and various optimization strategies like parameter sniffing. The content is supported by demonstrations and tools to analyze and enhance query performance.
Performance Tuning with Execution Plans
- 1. Performance Tuning with Execution Plans
- 2. GOAL • Show where, how and why performance issues appear within execution plans in order to better understand how to use execution plans to troubleshoot SQL Server query performance
- 4. Today’s Agenda • Introduction to Execution Plans • Common T-SQL Code Smells • Worked Examples • Querying the Plan Cache • More Worked Examples • Parameter Sniffing • Additional Tools
- 7. Execution Plans • Execution plans are a representation of the processes used by the query engine to perform the query submitted to SQL Server.
- 9. Optimizer • Cost-Based – Just an estimate – Not based on your computer • Statistics – Defined in indexes and tables – Must be maintained to ensure a good execution plan • Cache – Every query goes to cache (almost)
- 10. Generating a Plan • SQL Server Management Studio – Estimated – Actual • Procedure Cache – Estimated (sort of) • Extended Events – Estimated – Actual • Trace Events (not recommended) – Estimated – Actual
- 11. Tune the Query Small to medium, look at the query first Medium to large, go straight to the execution plan Very large and insane, query the execution plan Watch for low-hanging fruit Fix syntax over stats Stats over indexing Indexing over restructuring Restructuring Read the execution plan Understand the business needs
- 12. Where To Start?
- 13. Where To Start?
- 14. First Operator • Plan size • Compile time • Memory grant • Missing Indexes • Optimization level • Parameter – Compiled value – Runtime Value • Query hash • Reason for early termination • ANSI settings
- 15. Right to Left or Left to Right? • A clue: English • Another clue: These things
- 16. Left to Right or Right to Left • Answer: Both • Logical processing order: – Represents how the optimizer sees the query – Reading it from Left to Right • Physical processing order – Represents the flow of data – Follow the arrows/pipes from Right to Left • Both are necessary to understand certain plans
- 17. What Else to Look For • Warnings • Most Costly Operations • Fat Pipes • Extra Operations • Scans • Estimated vs. Actual
- 18. Demo
- 19. Summary • Execution plans are your view into the optimizer • You can capture plans multiple ways • You start with the first operator • Additional things to look for include: – Warnings – Most costly operations – Fat pipes – Extra operations – Scans – Estimated vs. Actual • Remember that these are just representations
- 22. Code Smells • A code smell is a piece of code that functions, but doesn’t function in the best possible way within a given set of circumstances
- 23. T-SQL Code Smells • Functions on Predicates • Data Conversion (Implicit & Explicit) • Cursors • Nested Views • IF Logic • Multi-Statement Table-Valued User Defined Functions
- 24. Demo
- 25. Worked Examples
- 26. Demo
- 29. Execution Plans From CacheSELECT TOP 10 SUBSTRING(dest.text, (deqs.statement_start_offset / 2) + 1, (CASE deqs.statement_end_offset WHEN -1 THEN DATALENGTH(dest.text) ELSE deqs.statement_end_offset - deqs.statement_start_offset END) / 2 + 1) AS querystatement, deqp.query_plan, deqs.query_hash, deqs.execution_count FROM sys.dm_exec_query_stats AS deqs CROSS APPLY sys.dm_exec_query_plan(deqs.plan_handle) AS deqp CROSS APPLY sys.dm_exec_sql_text(deqs.sql_handle) AS dest ORDER BY deqs.total_elapsed_time DESC;
- 30. Inside Execution Plans SELECT DB_NAME(deqp.dbid), SUBSTRING(dest.text, (deqs.statement_start_offset / 2) + 1, (CASE deqs.statement_end_offset WHEN -1 THEN DATALENGTH(dest.text) ELSE deqs.statement_end_offset END - deqs.statement_start_offset) / 2 + 1) AS StatementText, deqs.statement_end_offset, deqs.statement_start_offset, deqp.query_plan, deqs.execution_count, deqs.total_elapsed_time, deqs.total_logical_reads, deqs.total_logical_writes FROM sys.dm_exec_query_stats AS deqs CROSS APPLY sys.dm_exec_query_plan(deqs.plan_handle) AS deqp CROSS APPLY sys.dm_exec_sql_text(deqs.sql_handle) AS dest WHERE CAST(deqp.query_plan AS NVARCHAR(MAX)) LIKE '%StatementOptmEarlyAbortReason="TimeOut"%';
- 31. Interesting Dynamic Management Objects • Sys.dm_exec_query_plan • sys.dm_exec_query_profiles • Sys.dm_exec_text_query_plan
- 32. Demo
- 33. Additional Resources • Sp_whoisactive – Adam Machanic • Diagnostic Queries – Glen Berry • Performance Tuning with SQL Server Dynamic Management Views – Louis Davidson and Tim Ford
- 35. Demo
- 38. Parameter Sniffing • It’s a good thing… except when it isn’t • Automatic • Only works on parameters (with an exception) • It’s all about statistics – Average vs. Specific
- 39. Bad Parameter Sniffing • Differentiate from parameter sniffing • Still about statistics • Intermittent • Different plans • Focus on the compiled value • Compare to runtime • When it’s bad, it’s very bad
- 40. Local Variables • Eliminate parameters • Turn parameters into local variables • Produces “generic” plan
- 41. Variable Sniffing • The exception to parameters • Same process • Only works in a recompile situation • Invisible killer or guardian angel
- 42. OPTIMIZE FOR <value> • Specific and accurate • Changes over time • Produces “precise” plan
- 43. OPTIMIZE FOR UNKNOWN • For when you’re not sure • Changes over time • Produces “generic” plan
- 44. WITH RECOMPILE • Specific every time • Increases overhead • May be more costly than
- 45. Statistics • After all, it’s all about the statistics • Stats can age w/o updating • You may have auto-update turned off • Sampled updates may be inadequate • Filtered statistics may help
- 46. Plan Guides • Just a different way to use hints • Produces whatever plan you define
- 47. Turn Sniffing Off • Dangerous choice • Last for a reason • Very dangerous • Turns it all off • Everywhere • Did I mention it’s dangerous?
- 48. Demo
- 49. Additional Tools
- 51. Supratimas • Web based • Free • Easy to use • Limited Functionality
- 52. SQL Sentry Plan Explorer • Application • Free and Paid Version • Easy to Use • Extensive Funtionality
- 53. Query Store • Azure SQL Database • SQL Server 2016 • Guaranteed to change how you monitor and tune queries
- 54. Demo
- 55. Conclusion
- 56. Tune the Query • Small to medium, look at the query first • Medium to large, go straight to the execution plan • Very large and insane, query the execution plan • Watch for low-hanging fruit • Fix syntax over stats – Stats over indexing • Indexing over restructuring – Restructuring • Read the execution plan • Understand the business needs 56
- 58. Resources • Scarydba.com/resources • SQL Server Execution Plans • SQL Server Query Performance Tuning
- 59. Rate This Session Now! Rate with Mobile App: • Select the session from the Agenda or Speakers menus • Select the Actions tab • Click Rate Session Rate with Website: Register at www.devconnections.com/logintoratesession Go to www.devconnections.com/ratesession Select this session from the list and rate it Tell Us What You Thought of This Session Be Entered to WINPrizes! #ITDEVCON