1. Execution plans (300) Tomaž Kaštrun Spar ICS GmbH, Spar Slovenija
@tomaz_tsql

3. Agenda Basics of Query execution (warm-up Demo I)
Execution plan overview (Demo II)
Plan cache (Demo III)

4. Basics of Query execution
Is SQL Server a black box? Several steps on internal execution of query
1) Parsing all SQL Statements
Checks for typos, valid
Handles error messaginging
Breaks down into logical units, keywords, expressions, operators and identifiers
2) SQL Server creates Execution tree
Creates structure for query optimization;
MSSQL verifies that the tables and columns exists
Perform data conversion (implicit), replace views with definitions,
Performs simple syntax-based optimization
SQL Server creates milions of permutations of execution plans and checks which valid plan is the best for this query
3) SQL Server Optimizes a query
Perform trivial optimization (it is a „how-to“ join the tables, do some aggregations, order the data and retrieve the data)
Perform more sytactical transformation (if needed, perform full cost-based optimization (CBO))
Actual execution plan is generated here

5. Basics of Query execution
Is SQL Server a black box? Several steps on internal execution of query
4) Cache execution plan
SQL Server selects a execution plan (is estimates the cost of each of the plans and selects the plan with the lowest cost)
It has to do a cost-based balancing act, considering both the cost of finding the potential plan and the cost of the plans themselves (hence it is the biggest impact on the performance of your db)
Plan is stored in execution plan cache – it is a memory based SQL Server component for storing plans
If the plan is already available in cache, SQL Server can reuse it (instead of calculating it again)
5) Memory allocation
SQL server must allocate query memory for selected plan
Based on (up-to-date) statistics of the query, SQL Server grants the memory for usage
Statistics might be ouf-of-date, data distribution might be uneven for a particular tabel and SQL Server can allocate wrong amount of the memory
In case of wrong memory allocation (e.g.: sort operators, hash operators,…) SQL Server must spread over to temp db.
6) Execution
Huh…this was a loooooong way
Yeeeeh!  At last!

6. Basics of Query execution (simplified)
Query is submitted
When passing query to SQL Server, it goes to relational engine (relational engine is query processor with components helping to determine what query needs to do and how to do this).
Query is parsed
In relational engine, query goes through the process that checks that the T-SQL is written correctly, that it is well formed). Output of this process Parser process is a parse tree (or query tree (even called a sequence tree)). A parse tree represents the logical steps necessary to execute the requested query. * If query is not DML statement , but DDL, it will no be optimized, because there is only one right way for SQL Server to define an object, hence there are no opportunities for improvement.
Algebrizer
A parse tree is passed on to query algebrizer. Algebrizer resolves the names of objects, tables and columns. It identifies also the individual column level such as data types, locations of aggregation (SUM, COUNT, GROUP BY,..). Algebrizer outputs a binary called query process tree, which is sent to query optimizer. Output includes a hash coded value representing a query.
!!!! If the plan is available, process stops here and existing plan is selected.
Query optimizer

7. Basics of Query execution

8. Logical query processing (thanks Itzik Ben-Gan)
My Query:
(8) SELECT
(9) DISTINCT
(11) <TOP_specification>
<select_list>
(1) FROM <left_table>
(3) <join_type> JOIN <right_table>
(2) ON <join_condition>
(4) WHERE <where_condition>
(5) GROUP BY <group_by_list>
(6) WITH {CUBE | ROLLUP}
(7) HAVING <having_condition>
(10) ORDER BY <order_by_list>
Actual query processing:
1. FROM
2. ON
3. OUTER (join)
4. WHERE
5. GROUP BY
6. CUBE | ROLLUP
7. HAVING
8. SELECT
9. DISTINCT
10. ORDER BY
11. TOP
Source: Inside Microsoft SQL Server™ 2005 T-SQL Querying, Itzik Ben Gan

9. Query optimization
Execution plans and cost-based optimization Optimization phases Index and distribution statistics Join selection (three types: nested loop, hash and merge join) On clause (with respect to indexes) Where clause (with respect to distribution statistics)

10. Plan re-usage „On going“ debate: - to use stored procedures
Execution plan is cached
Better security, no SQL Injections
Seldom recompilation of plans
- ad-hoc queries
Execution plan is compiled every time
Weaker security, with possible SQL Injections
Less prone to errors

11. Plans, plans, plans….what are they?
- Is a best-cost strategy by the optimizer how to access (and manipulate – in case od DML) data
Is SQL server smarter than developer? Or is developer smarter when using QUERY HINTS?
- Optimizer‘s key decisions are made here
(refer to logical query processing)
How to perform JOIN, ON operations and what is correct table order
Which data should be aggregated (SUM, COUNT, DISTINCT, COUNT) and which ordered (ORDER BY)
Which are the proper indexes to use
AND!!! Can cached plan be reused?

12. Execution plan overview
- Understanding execution plans is important! Why?
Insight into SQL internals
If we don‘t know what SQL Server is doing, we don‘t know what is wrong with our query
Troubleshooting the query performance -> tuning query performance
Understanding execution and processing strategy
Why CPU is high? Why my I/O is high? -> is it hardware problem or you need to refactor your code

13. Estimated vs. Actual execution plan
Estimated execution plan
Is the output of the optimizer
Operations and steps within the plan are logical steps (they represent how optimizer is seeing the plan and don‘t represent what physically occurred)
Using the statistics for estimation
Actual execution plan
Is the plan of actual query execution
It shows data representing what actually happened to the data
Using actual data for plan

14. Estimated vs. Actual execution plan
When can estimated and actual plan differ?
Most of the time they will be the same!
But can differ:
When statistics on the table/index are out of date
When estimated execution plan is not valid any longer due to recompiles (lazy writer) and it will delete and create new one
Any other changes that occur as the storage engine process the query.
Plus side:
Estimated plans don‘t access data and can be useful for large and complex queries.

15. Type of execution plans
Text (depricated)
XML
Graphical (SSMS built-in, based on XML file)

16. Plan reuse Generating execution plans is expensive
Algebrizer process creates hash of the query (like fingerprint or like signature)
With this hash sql server compares hash queries in cache and if query exists in cache that matches the query coming into the engine, the cost of optimization process is skipped and execution plan is reused.

17. Plan reuse Good practices
Best practice is to write query in such way that SQL Server can reuse it‘s plan
Hence stored procedures or parameterized queries are the best
If variables are hard-coded, the smallest change to the string that defines a query can cause a cache miss and new plan is created.
SQL server doesn‘t keep execution plan in cache for ever.

18. Lazywriter Formula for slowly aging execution plans is calculated with
internal process named lazywriter
Plan of cost X is referenced Y times. When X*Y value is higher than Z, plan is considered „aged“ and hence removed from cache.

19. Reasons for plan recompilation
Changing stucture of table or schema used by query
Changing index used by query
Dropping/rebuilding index used by query
Updating the statistics used by query
Large UPDATEs, large INSERTs
Causing deferred recompile due to mixing DDL and DML in single query
Changing SET options within the execution of the query
Changing stucture or schema of temporary table
Changing dynamic views, cursor options
Parameters sniffing …

20. Reading Execution plans
SHOWPLAN permission needs to be granted
Execution plan is series of sequential operators
Are executed one after another
Are read from top to bottom and right to left.

21. Demo 1

22. Operator Properties
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
Actual Number of Rows - The actual number of rows if the query was run.
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. 

23. Common Operators Estimated number of rows Estimated row size
Physical operation
Logical operation
Estimated I/O cost
Estimated CPU cost
Estimated operator cost
Estimated subtree cost

24. Common Operators Data Retrieval operators Join operators
Table scan
Index scan (clustered, nonclustered)
Index seek (clustered, nonclustered)
Join operators
Merge join (must have sorted input)
Hash join (internal hash table)
Nested loop join (outer join, inner join)
Aggregation operators (group by)
Stream aggregate (when data is presorted)
Hash aggregate (data are not presorted, SQL Server is granted memory for working with temporary tables)
Lookup Operators
Key Lookup
RID Lookup
Others:
Compute scalar
Filter
Sort
Top
Source:

25. Joins - Nested loop join Data are not sorted in any of input tables
SQL server make outer loop, with result it makes inner join
„RBAR“ operator
Makes output from one table and triggers another RBAR operator
Very inefficient when outer table is large table (and inner table has only a few records)!

26. Joins
- Merge join
Data are pre-sorted in both of input tables (data are presorted by using index, or SQL Server is using explicit sort operator )
SQL server reads each record in merge operation just once
(in comparison to nested loop join)
Efficient join

27. Joins
- Hash join
Needs at least one equijoin predicate (is condition used in join predicate to compare values from one table to another)
Reads rows from one input, hashes the rows into in-memory hash table, repeats for second input and returns mathing rows
Apply hash function, uses hash buckets
build and probe phase
Needs memory grant to build hash table
Useful for largers tables (datawarehouse) with unindex columns
Very efficient

28. Key Lookup
Key lookup operator (there are two RID and Key) is required to get data from clustered index (or non-clustered index) but is not in a covering index.
Covering index is a non-clustered index that contain all the needed columns from select list or join predicate
Optimizer can not retrieve the rows in a single operation and it has to use a clustered key (or ID in heap) to return corresponding rows

29. RID Lookup
RID (Row ID) lookup operator is heap equivalent to Key Lookup operator.
When there is no clustered index and query must get all the data to satisfy the query, additional operation is required to get the data
A type of bookmark lookup, which uses a row identifier to find the rows to return.
Adds additional disk I/O –> two operations instead of a single operation

30. Compute scalar
Computer scalar is an operator that evaluates an expression to procude a scalar value or a single defined value.
It may be returned to the user or referenced in the query.
Is result of calculation, string concatenation.

31. Filter
Filter operator is applied to limit the output of the values in selected column
By adding HAVING clause, FILTER operator is added to execution plan.

32. Sort Sort operator sort all incoming rows for selected column
By adding ORDER BY predicate, SORT operator is added to execution plan.
Actual Rebinds, Actual Rewinds

33. Actual rebinds, actual rewinds
Sort operator is one of few to use actual (or estimated) rebinds and rewinds
When sort operator occurs, following will happen:
Init()method is called
physical operator (sort) is initialized and any data structure can be set up
GetNetx()method is called
physical operator gets (receives) the rows of data to work on it. It can receive several or none
Close()method is called
physical operator has performed its job and is cleaned and shut down.
Only a single close method is received

34. Actual rebinds, actual rewinds
Rebind or rewind is a count of the numbers of times the init()method is called by operator (sort).
A rebind occurs when one or more correlated parameters of the nested loop join change and the inner side (of nested loop) must be reevaluated
A rewind occurs when none of correlated parameters change and the prior inner result set may be reused.
Example:
Rebind = 1; init() method was called one time on a sort operator that is not on the inner side of a loop join.

35. Actual rebinds, actual rewinds
Following operators use rebinds and rewinds:
Non-clustered Index Spool
Row Count Spool
Table Spool
Sort
Table-Valued Function
Remote Query

36. Demo 2

37. Capturing Plans - Using SQL Management studio - SQL Profiler
When working on production
When working with several concurrent sessions
Tracing several components
Storing to XML
Additional cost on server!

38. Plan Cache - Why caching execution plans?
Because creation of the execution plans takes resources and time.
Each unique query gets a „hash“ or „fingerprint“ or binary …
it gets an execution plan
Plans are stored in plan cache
Cache is internal memory storage
Available in: sys.dm_exec_cached_plans
Performance questions

39. Sys.dm_exec_cached_plans
Structure of DMV:
Refcounts – number of cache objects that are referencing this cache object
Usecounts – number of the cache objects has been used (plan has been used).
Size_in_bytes – number of bytes used by plan
Memory_object_address – memory address of the cached entry
Cache_objects – type of objects in the cache:
Compiled plan – Complited execution plan
Compiled plan Stub
Parse tree - a plan stored for viewin
Extended Proc
CLR compiled Proc / Func
Objtype – tye of object:
Proc – stored procedure
Prepared - Prepared statement
Adhoc – Ad hoc query
View
Trigger
Default
UsrTab – User table
SysTab – Sytem Table
Rule
Check – check constraint
Plan_handle – identifies for the in-memory plan.
Source:

40. Cache plans with plan handle
SELECT
cp.refcounts
,cp.usecounts
,cp.objtype
,st.[dbid]
,st.objectid
,st.[text]
,qp.query_plan
,cp.plan_handle
FROM sys.dm_exec_cached_plans AS cp
CROSS APPLY sys.dm_exec_sql_text(cp.plan_handle) AS st
CROSS APPLY sys.dm_exec_query_plan(cp.plan_handle) AS qp; GO
Using dm_exec_sql_text to retrieve T-SQL statement
Using dm_exec_query_plan to retrieve an XML execution plan (can be graphically opened or stored in file)
Requires VIEW SERVER STATE permission on the server!

41. Plan cache polluting For Example:
SELECT *
FROM adventureworks2012.[dbo].[DatabaseLog]
WHERE
DatabaseLogID = 1;
DatabaseLogID = 2;
This generates two different Execution plans.
Solution: Create parametrized query

42. Clearing CACHE Using: Or using:
DBCC FREEPROCCACHE; GO
DBCC FREEPROCCACHE(0x D02F0D740EB );
It removes all (or a specific) plan from a plan cache.
Or using:
DBCC FREESYSTEMCACHE(‚ALL‘);
It cleans all unused cache entries from all caches.
SQL Server proactively cleans up unused cache in the background.

43. Cache aging
Plan „age“ is calculated using Age (Lazywriter) and cost (cost of the plan)
Each time plan is used, Lazywriter increments age by 1
Plan cache is cleaned periodically (and decreased by 1)
Plan is removed from cache when:
Memory manager requires more memory
All available memory is currently in use
Age = 0
Is not referenced by any query (session)
IF all criteria are fulfilled, cache plan is deleted.

44. Demo 3