Dave Bland LinkedIn Daveb8782@gmail.com SQL Server Execution Plans: How to use them to find performance bottlenecks Dave Bland LinkedIn Daveb8782@gmail.com.

Slides:



Advertisements
Similar presentations
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide
Advertisements

Understanding SQL Server Query Execution Plans
Module 13: Performance Tuning. Overview Performance tuning methodologies Instance level Database level Application level Overview of tools and techniques.
CS 245Notes 71 CS 245: Database System Principles Notes 7: Query Optimization Hector Garcia-Molina.
EXECUTION PLANS By Nimesh Shah, Amit Bhawnani. Outline  What is execution plan  How are execution plans created  How to get an execution plan  Graphical.
Virtual techdays INDIA │ 9-11 February 2011 SQL 2008 Query Tuning Praveen Srivatsa │ Principal SME – StudyDesk91 │ Director, AsthraSoft Consulting │ Microsoft.
Database Systems: Design, Implementation, and Management Eighth Edition Chapter 11 Database Performance Tuning and Query Optimization.
Relational Database Performance CSCI 6442 Copyright 2013, David C. Roberts, all rights reserved.
Database Systems: Design, Implementation, and Management Tenth Edition Chapter 11 Database Performance Tuning and Query Optimization.
Database Systems: Design, Implementation, and Management Eighth Edition Chapter 10 Database Performance Tuning and Query Optimization.
Module 12: Optimizing Query Performance. Overview Introducing the Query Optimizer Tuning Performance Using SQL Utilities Using an Index to Cover a Query.
Denny Cherry Manager of Information Systems MVP, MCSA, MCDBA, MCTS, MCITP.
Module 7 Reading SQL Server® 2008 R2 Execution Plans.
Ashwani Roy Understanding Graphical Execution Plans Level 200.
Primary Key, Cluster Key & Identity Loop, Hash & Merge Joins Joe Chang
Performance Dash A free tool from Microsoft that provides some quick real time information about the status of your SQL Servers.
1 Chapter 10 Joins and Subqueries. 2 Joins & Subqueries Joins – Methods to combine data from multiple tables – Optimizer information can be limited based.
Microsoft AREC TAM Internship SQL Server Performance Tuning(I) Haijun Yang AREC SQL Support Team Feb, SQL Server 2000.
Query Optimizer Execution Plan Cost Model Joe Chang
Query Optimization CMPE 226 Database Systems By, Arjun Gangisetty
1 Chapter 9 Tuning Table Access. 2 Overview Improve performance of access to single table Explain access methods – Full Table Scan – Index – Partition-level.
Eugene Meidinger Execution Plans
Dave LinkedIn
How to kill SQL Server Performance Håkan Winther.
SQL Server Statistics DEMO SQL Server Statistics SREENI JULAKANTI,MCTS.MCITP,MCP. SQL SERVER Database Administration.
Execution Plans for Mere Mortals A beginners look at execution plans. Mike Lawell, Teammate, Linchpin People.
Scott Fallen Sales Engineer, SQL Sentry Blog: scottfallen.blogspot.com.
Execution Plans Detail From Zero to Hero İsmail Adar.
SQL Server Statistics DEMO SQL Server Statistics SREENI JULAKANTI,MCTS.MCITP SQL SERVER Database Administration.
Diving into Query Execution Plans ED POLLACK AUTOTASK CORPORATION DATABASE OPTIMIZATION ENGINEER.
Data Integrity & Indexes / Session 1/ 1 of 37 Session 1 Module 1: Introduction to Data Integrity Module 2: Introduction to Indexes.
SQL IMPLEMENTATION & ADMINISTRATION Indexing & Views.
SQL Server Statistics and its relationship with Query Optimizer
Practical Database Design and Tuning
Indexes By Adrienne Watt.
Execution Planning for Success
Query Tuning without Production Data
Database Performance Tuning &
Query Tuning without Production Data
Reading execution plans successfully
Database Performance Tuning and Query Optimization
Reading Execution Plans Successfully
Evaluation of Relational Operations
Introduction to Execution Plans
Chapter 15 QUERY EXECUTION.
Database Management Systems (CS 564)
Third Party Tools for SQL Server
The Key to the Database Engine
Cardinality Estimator 2014/2016
Physical Join Operators
Dave LinkedIn SQL Server Execution Plans: How to use them to find performance bottlenecks Dave LinkedIn.
Physical Database Design
JULIE McLAIN-HARPER LINKEDIN: JM HARPER
Execution Plans Demystified
Statistics: What are they and How do I use them
Practical Database Design and Tuning
Transactions, Locking and Query Optimisation
Reading Execution Plans Successfully
SQL Server Query Plans Journeyman and Beyond
Query Processing CSD305 Advanced Databases.
Introduction to Execution Plans
Chapter 11 Database Performance Tuning and Query Optimization
EXECUTION PLANS Quick Dive.
Execution plans Eugene
Diving into Query Execution Plans
SQL Server Query Design and Optimization Recommendations
Introduction to Execution Plans
Reading execution plans successfully
Introduction to Execution Plans
Presentation transcript:

Dave Bland LinkedIn Daveb8782@gmail.com SQL Server Execution Plans: How to use them to find performance bottlenecks Dave Bland LinkedIn Daveb8782@gmail.com

Thank You Sponsors

About Me 14 years DBA Experience 6 years DBA consultant for Einstein Technology Solutions 18 years of teaching SQL Server 30 years of teaching 5 years SQL Server Instructor at Harper College, Palatine, IL Currently supervise the Shared Services DBA team for Stericycle(3 years)

Certifications

Agenda Types of Execution Plans First Look at an Execution Plan Execution Plan Operators and Identifying potential performance bottlenecks How to view the plans SQL Sentry Plan Explorer “When writing an sql statement, you are telling SQL Server what you want, not how you want SQL Server to do it.” – Brian Hansen

Questions That Can Be Answered Are indexes being used? Is the proper index being used? Are joins using the best physical join? Are indexes missing? Is there any unexpected processing? Where are the bottlenecks in the query? Is the problem in the database?

What is an Execution Plan? How SQL Server will execute a query SQL Server may create more than one plan Uses Statistics to determine the best plan to use

Requirements to View Execution Plans Minimum permissions needed: ShowPlan in the database Members of Sysadmin role Members of DB_Owner

Types of Plans and Displaying Execution Plans Actual Estimated Displaying Execution Plans Graphical plans XML plans Saving .SQLPLAN SQL Servers uses statistics to create the execution plan for both actual and estimated plans “The estimated execution plan is designed to show what SQL Server would most likely do if it were to execute the query. Using statistics, it estimates how many rows may be returned from each table. It chooses the operators it will use to retrieve the data – scans or seeks. It decides how to best join the tables together – nested loops, merge joins, hash joins. It is a reasonably accurate guide to what SQL Server will do” - Jes Schultz Borland at BrentOzar.com Keep statistics up to date for the best possible execution plan Estimated execution plans are not stored in cache Demo #1

Plan Reuse A Hash is created for the incoming query What flushes a plan from Cache Not enough memory DBCC FREEPROCCACHE Schema Changes to referenced objects Statistics used by the plan are updated Changes made to the stored procedure

First Look at Execution Plan With this slide things the should jump out as potential points of optimization Is the TOP really needed? The Table Scan The 78% for the FactFinance table The thick line coming out of the table scan The Nested Loop The missing index

ToolTip Popups Used for comparative purposes Float cursor over icon Operation metrics. Physical Operation - the physical operation for this part of the execution plan, such as joins, seeks, scans... Logical Operation - the logical operation for this part of the execution plan Estimated I/O Cost - these are relative values used for presenting whether a given operation is I/O intensive. The Query Optimizer assigns these values during parsing and they serve only as a comparative tool to aid in determining where the costs of a given operation lie. The larger the value, the more cost-intensive the process. Estimated CPU Cost - these are relative values used for presenting whether a given operation is CPU intensive. The Query Optimizer assigns these values during parsing and they serve only as a comparative tool to aid in determining where the costs of a given operation lie. The larger the value, the more cost-intensive the process. Estimated Operator Cost - This is the summation of the I/O and CPU estimated costs. This is the value that is also presented under each operation icon in the graphical execution plan. Estimated Subtree Cost - This is the total of this operation's cost as well as all other operations that preceded it in the query to this point. Estimated Number of Rows - This value is derived based upon the statistics available to the Query Optimizer at the time the execution plan is drafted. The more current (and the larger the sampling size of the statistics) the more accurate this metric and others will be when compared to the actual data. Estimated Row Size - Also based upon the statistics available at the time of parsing, this value corresponds to how wide the Query Optimizer believes the affected rows to be. The same rule applies to statistics here as well as with the Estimated Number of Rows - the more current and descriptive the data set used to generate the statistics - the more accurate this value will be in comparison to the actual data. Good stats also lead to better (more accurate) decisions made by the Query Optimizer when actually processing your queries. Ordered - is a Boolean value signifying whether the rows are ordered in the operation. NodeID - Is the ordinal value associated with this particular operation in the query execution plan. Oh, and thank you for the confusion Microsoft for numbering the operations in a left-to-right fashion, even though we are to read the execution plans right-to-left. Greatly appreciated!

Seeks vs Scans Index Scan vs Index Seek Scan Seek Scan searches data pages Seek is preferred for highly selective queries If scan, check for index or a useful index WHERE lastname LIKE '%smit%' Demo #3\3A

Table Scan Usually considered less than optimal Can happen if there are not any useful indexes If table is very small may not be an issue If expecting an Index Seek and not getting it: Update statistics Rebuild indexes

Physical Join Operators Demo #4 Nested Loop Compares each row from one table with the other table One input is small other is Indexed properly Not supported with a Right Outer Join Performance is proportional to the amount of data being retrieved Query optimizer can under estimate the number of rows Merge Usually most efficient method of joining tables Requires both join input to be sorted on the merge columns Less I\O Requires at least one column to be unique Hash Uses a build input and a probe input Two phases: Build and Probe Works best with non indexed columns Three Types In-Memory Hash Grace Hash Recursive Hash There are three main kind of hash joins. 1) In-memory hash join  In build phase table fit completely in memory. 2) Grace hash join  In build phase table does not fit completely in memory and spans to disk. 3) Recursive hash join In build phase table is very large and have to use many levels of merge joins

Parallelism Can be difficult to test on a development machine Demo #5 Not all operators are suitable to be used in a parallel plan. The Optimizer will only choose a parallel plan if: the server has multiple processors, the maximum degree of parallelism setting allows parallel plans, and the cost threshold for parallelism sql server configuration option is set to a value lower than the lowest cost estimate for the current plan. Note that the value set here is the time in seconds estimated to run the serial plan on a specific hardware configuration chosen by the Query Optimizer team. The cost of the parallel plan is cheaper than the serial plan. If all these criteria are met, then the Optimizer will choose to parallelize the operation. Demo #5

Unexpected Processing Use of cursor with sys.sp_Msforeachdb Data type conversions Expecting a Clustered Index Seek, getting a Non-Clustered Index Scan Foreign Key full table scan due to lack of index Demo #6

CONVERT_IMPLICIT Happens when joining on different data types Can lead to excessive CPU utilization Can occur in the FROM or the WHERE clause Demo #7

Other Operators Sort Key Look up Compute Scalar Demo #8A Demo #8

Missing Missing Statistics Missing Join Operator Conversion Warning Demo # 9 Missing Statistics Missing Join Operator Conversion Warning

Using Activity Monitor What is running Now – Example 10

Extended Events Demo # 11

Live Query Stats Demo #12

Compare Two Plans Demo #13

SQL Sentry Plan Explorer Demo #14

Solutions Table redesign Redesign query More memory Add Indexes Optimize indexes Update statistics Reboot

Resources Used Microsoft SQL Server 2014 Query Tuning and Optimization – Benjamin Nevarez www.sql-server-performance.com https://msdn.microsoft.com http://sqlblog.com/blogs/paul_white http://www.scarydba.com Paul White Blog

Resources Used Understanding Parallelism BrentOzar.com SQL Server Execution Plans – Grant Fritchey https://msdn.microsoft.com

Questions

Thank You!!