1. An Introductory Look at Execution Plans
Eric Wisdahl
SQL Saturday #564 – Orlando, FL 2016

2. Who Am I? Principal Architect at eCommerce Company
SQL Server 2012 MCSA / MSCE; 2008 MCTS / MCITP
Blah Blah Blah.

3. Agenda Why do we want to look at Execution Plans?
What should we be aware of?
What types of plans are there?
How and when do you get to the plans?
How do we read the plans?
Other Methods for Reading Plans?
How can we break down the plans for tuning?
Talk about the fact that we will be switching between the slides and the demos. I will include the demos along with the presentation prior to the conference and it should be available afterwards as well from the SQL Saturday site…

4. Benefits
Show what is going on “behind the scenes” as prescribed by the optimizer
Which indexes are used
How data is being joined
How aggregates are put together
Costs for I/O and CPU
Can be saved and shared for debugging / tuning
Corresponds to the “Why do we want to look at execution plans?” question.

5. Warnings
Not all execution plans can be created for all scripts or commands. (i.e. temp tables / variables)
Operation percentages and costs are ratios or scoring estimates, not hard numbers…
And they can be wrong.
Corresponds to the “What should we be aware of?” question…

6. Execution Plan Types Estimated execution plan Actual execution plan
Live execution plan *
Why are they different?
Corresponds to the “What types of plans are there?” question.
Estimated plans show how the query optimizer believes that it will act when the query is presented to it. Actual plans, for the most part, report what actually happened. The optimizer will sometimes generate differences between what it estimates it will do and what it actually does, due to stale statistics, overly complex queries, parallelism, and portions of the query not being able to be performed prior to actual execution (i.e. using a temp table or other object that is not available if the statement is not actually run).
Live execution plans are available in the 2016 release, but you need to enable it for your session. Still it looks beyond awesome! (

7. Execution Plan Output Text plans * XML Graphical Simple text
Record-set based
XML
Graphical
* text plans will be removed in a future version.
Corresponds to the “How and when do you get to the plans?” question – part 1.
Make sure to mention that the text plans will be eliminated shortly. Also, note the difference between the pure text plan and the text plan that is brought back in record-set format. Note that the XML format plan actually brings back more information than the graphical plan, and can be used to generate the graphical plan. Make sure to mention that the xml plan (and grahical saved as XML) can be saved and passed between developers, etc to show what was going on at the time of the problem.

8. SSMS – GUI GUI – display actual / estimated buttons
Shortcuts - control ‘M’ / control ‘L’
Query menu – choose item
Right click on query window – choose item
Corresponds to the “How and when do you get to the plans?” question – part 2.
There are many ways to get to the same commands inside of the management studio tool. You can use the buttons on the tool bar, the query menu, the menu accessible when you right click the background of the query window or shortcuts. Each have the same result, which is to toggle the display estimated or actual execution plans. These two operations are exclusive, so you will only ever display the estimated plan or the actual plan.

9. Demo 01

10. T-SQL Commands Estimated - SET SHOWPLAN_? ON / OFF
ALL
TEXT
XML
Actual - SET STATISTICS ? ON / OFF
PROFILE
Corresponds to the “How and when do you get to the plans?” question – part 3.
You can also use T-SQL to set the commands to return the execution plans as part of the result set. You use the set showplan options to bring back the estimated execution plans, while you use the set statistics to bring back the actual execution plans. However, note that both of these options are overridden by the options chosen through the GUI. Bringing back the SHOWPLAN_ALL is similar to the TEXT except that each plan row element is returned as a row. The TEXT plan has the entire execution plan returned in a single column. The XML option brings back the most information, more even than the graphical plan.

11. Demo 02

12. DMOs Use sys.dm_exec_* DMOs to find the plans stored in the cache
cached_plans
plan_attributes
query_plan
sql_text
query_stats
text_query_plan
Only displays the “estimated execution plans”
Only if the query is still in cache
Very cheap as the information is already in cache.
Corresponds to the “How and when do you get to the plans?” question – part 4.
These DMOs can be used to tie together queries for what is currently running, to what has been run recently. You use the sql_handle to get to the particular query. The sys.dm_exec_query_plan holds most, but not all, query plans. Those very large query plans will only be available in the sys.dm_exec_text_query_plan. However, these can be returned and saved as an XML file and then investigated. Note that the optimizer will often use query hashes to group similar query plans together. These query hashes can be used to gather statistics on similar queries.

13. Demo 03

14. Extended Events / Profiler
Use extended events or profiler to create sessions to view history of queries run and associated query execution plans
Can display either actual or estimated
Only for records returned by the session
Very costly!
Corresponds to the “How and when do you get to the plans?” question – part 5.
SQL Server Profiler can be used to create the scripts for traces, or the traces can be manually constructed. You can also simply run the profile from the GUI. However, this is not advised as it generates more overhead. Note that you should use profiler to gather the execution plans very cautiously as it GREATLY increases the size of the record returned for every query. Make sure that you properly filter the returned records to reduce the cost in storage space and resources.
With that said, SQL Server Extended Events have been ushered in as the replacement for Profiler and we should begin to use these instead. For SQL Server Extended events we use the query_post_execution_showplan event to retrieve the execution plan. Unfortunately, it is costly as it must generate the data for every query coming through, rather than limiting the sessions to identify which we should look at that plan. Yikes!

15. Live!
With 2016 we have the ability to see Live Execution Plans

16. Demo 04

17. Reading Graphical Plans
Read top to bottom, left to right
Data flows right to left, it’s confusing.
Arrows represent flow of data
Thickness of arrow ~= amount of data
Percentage displayed per operator
Not always correct
Ratios not real numbers
Object type icons
Tool-tips and properties
Corresponds to the “How do we read the plans?” part 1.

18. Object Types
Total of 85 operators available with an Icon, (23 listed with no icon) broken into four types
Logical and physical operators – A.K.A. iterators (Blue)
Parallelism physical operators (Blue)
Cursor operators (Yellow)
Language elements (Red)
Split between the “Corresponds to the “How do we read the plans?” and “How can we break down the plans for tuning?” questions.
For 2008 R2 You can search Books Online for “Graphical Execution Plan Icons”.
For
For 2014 –
For
Logical and Physical Operators –
Aggregate, Arithmetic Expression, Assert, Async Concat (No Icon), Bitmap, Bitmap Create, Bookmark Lookup (Not Used in 2012 and above – Instead Clustered Index Seek + RID Lookup or Key Lookup), Broadcast, Build Hash (Columnstore), Cache (Type of Spool, Not Used in 2012 and above), Clustered Index Delete, Clustered Index Insert, Clustered Index Merge, Clustered Index Scan, Clustered Index Seek, Clustered Index Update, Collapse, ColumnStore Index Scan, Compute Scalar, Concatenation, Constant Scan, Cross Join, Delete, Deleted Scan, Distinct (No Icon), Distinct Sort (No Icon), Eager Spool, Filter, Flow Distinct (No Icon), Full Outer Join, Hash Match, Index Insert, Index Scan, Index Seek, Index Spool, Inner join, Insert, Inserted Scan, Iterator Catchall, Key Lookup, Lazy Spool, Left Anti Semi Join (No Icon), Left Outer Join, Left Semi Join, Log Row Scan, Merge Interval, Merge Join, Nested Loops, Nonclustered Index Delete, Nonclustered Index Update, Online Index Insert, Parameter Table Scan, Remote Delete, Remote Index Scan, Remote Index Seek, Remote Insert, Remote Query, Remote Scan, Remote Update, RID Lookup, Right Anti Semi Join, Right Outer Join, Right Semi Join, Row Count Spool, Segment, Sequence, SequenceProject, Sort, Split, Spool, Stream Aggregate, Switch, Table Delete, Table Insert, Table Scan, Table Spool, Table Update, Table-valued Function, Top, Top N Sort, UDX, Union, Update, Window Spool
Parallelism Physical Operator –
Branch Repartition, Distribute Streams, Repartition Streams, Gather Streams, Partial Aggregate, Segment Repartition
Cursor Operators –
Cursor Catchall, Dynamic, Fetch Query, Keyset, Population Query, Refresh Query, Snapshot
Language Elements –
Assign, Convert, Declare, If, Intrinsic, Language Element Catchall, Result, While

19. Tool Tips and Properties
Tool tips – hover over operator or arrow
Properties window gives all this and more.
Examples
Cached plan size
Number of rows (estimated and actual)
I/O and CPU costs (estimated and actual)
Output lists
References and predicates
Operator cost
Sub-tree cost
Etc.
Corresponds to the “How do we read the plans?” and “How can we break down the plans for tuning?” questions part 2.

20. Sources Table scan Clustered index scan Clustered index seek
Key lookup
RID lookup
Table valued function
Etc.
Corresponds to the “How do we read the plans?” and “How can we break down the plans for tuning?” questions part 3.
Most often we will see the table scan, clustered index scan / seeks, or non-clustered index scan / seeks. The bookmark lookup means that we have used an index to identify the rows to return, but that the index does not contain all of the attributes necessary for the returned result set. As such, it will need to go back to the base table to get the other attributes. The RID Lookup is similar, but with a heap instead of a table with a clustered index.

21. Other Areas Order By Aggregate Views Stored procedures Triggers
Derived tables
Common table expressions
Cursors
Etc.
Corresponds to the “How do we read the plans?” and “How can we break down the plans for tuning?” questions part 4.
Order by - uses the sort to order the result set, if necessary. At other times, the data is presorted and no sort is necessary.
Aggregates – use Hash Match (aggregate) to create a hashing table that aggregates the data, usually followed by a compute scalar.
Views – if the view is non-indexed, the underlying query is used directly. If the view is indexed, it behaves as though the view were a table
Stored Procedures – The individual statements within the stored procedure are performed. This can be problematic in producing an estimated execution plan if there are temp tables or variables within the stored procedure.
Triggers – triggers are not seen at all when using the estimated plans. When retrieving the actual execution plan, the effects of the trigger are seen as a second (or nth) plan returned along with the normal execution plan.
Derived Tables – like a virtual table created on the fly within a select statement.
Common table expressions – similar to derived tables and sub-queries. Common table expressions are essentially “temporary result set” that exists only within the scope of a single sql statement. They are, however, unique in that you can perform recursive queries with them, which will use a table spool to hold the records which might invoke multiple passes through loops.
Cursors – Beyond the scope of the presentation, I will provide a sample cursor to show the differences between the estimated and actual execution plans.

22. Reading Graphical Plans II
Can use Sentry One Plan Explorer.
Might be considered a cleaner shape.
Break down by CPU or IO
Shows what columns are being brought in by what object
Ability to post an anonymized plan for feedback / help
Free!

23. Joins Nested loops join Merge join Hash Match (join)
See Craig Freedman’s “Summary of Join Properties” for explanation of the physical join operators.
Corresponds to the “How do we read the plans?” and “How can we break down the plans for tuning?” questions part 5.
Joins are some of the most important operators while looking at execution plans. It is important to note that there is no “best” join algorithm and that no join algorithm is inherently good or bad. Each algorithm performs well in the right circumstances and poorly in the wrong circumstances.
Nested Loop Join: Perform a search on the inner table for each row of the outer table, typically using an index
Good:
Small Record Sets
Merge Join: Used for one to many and many to many join operations. Merge joins occur on tables where the join columns are pre-sorted, or if the query optimizer determines it would be cheaper to sort the data and then use the merge join operation than to use either the nested loop or hash match joins.
Hash Match (Join): Builds a hash table from the smaller table (build input). Next, for each row of the larger table (probe row) computes a hash value and looks for matches in the hash table.
Large data sets, particularly if one of the tables is much larger than the other
Tables which are not sorted on join columns
No usable indexes
Might indicate:
Missing or incorrect index
Missing where clause
Function which makes the where clause non-sargable.
Read Craig Freedman’s SQL Server Blog for an excellent series of articles (overview - “Summary of Join Properties”) on the various joins that SQL Server Uses

24. Demo 05

25. References SQL Server Execution Plans
Grant Fritchey
Free E-Book (Print Version Available)
SQL Server 2012 Query Performance Tuning Distilled
Inside SQL Server 2008: T-SQL Querying
Itzik Ben-Gan, et al.
Complete Showplan Operators
Fabiano Amorim
Mention Paul Whites blog posts, Rob Farelys, etc.

26. Questions

27. Thank You