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

2. Thank You Sponsors

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

4. Certifications

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

21. Using Activity Monitor
What is running Now – Example 10

22. Extended Events
Demo # 11

23. Live Query Stats
Demo #12

24. Compare Two Plans
Demo #13

25. SQL Sentry Plan Explorer
Demo #14

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

27. Resources Used Microsoft SQL Server 2014 Query Tuning and Optimization
– Benjamin Nevarez
Paul White Blog

28. Resources Used Understanding Parallelism BrentOzar.com
SQL Server Execution Plans – Grant Fritchey

29. Questions

30. Thank You!!