Microsoft SQL Server 2008 R2 Unleashed- P137 docx

Physical Operation—Lists the physical operation being performed for the node, such as a Clustered Index Scan, Index Seek, Aggregate, Hash or Nested Loop Join, and so on.. The ToolTips f

Execution Plan ToolTips

When a graphical execution plan is presented in the Query Analyzer, you can get more

information about each node in the execution plan by moving the mouse cursor over one

of the icons ToolTips for estimated execution plans are slightly different from the

ToolTips displayed for an execution plan that is generated when a query is actually

executed The ToolTip displayed for an estimated execution plan provides the following

information:

Physical Operation—Lists the physical operation being performed for the node,

such as a Clustered Index Scan, Index Seek, Aggregate, Hash or Nested Loop Join,

and so on

Logical Operation—Lists the logical operation that corresponds with the physical

operation, such as the logical operation of a union being physically performed as a

merge join The logical operator, if different from the physical operator, is listed in

parentheses below the physical operator in the icon text in the graphical execution

plan Essentially, the logical operators describe the relational operation used to

process a statement, while the physical operation describes how it is being

performed

Estimated I/O Cost—Indicates the estimated relative I/O cost for the operation

Preferably, this value should be as low as possible

Estimated CPU Cost—Lists the estimated relative CPU cost for the operation.

Estimated Number of Executions—Lists the estimated number of times this

oper-ation will be executed

Estimated Operator Cost—Indicates the estimated cost to execute the physical

operation For best performance, you want this value as low as possible

Estimated Number of Rows—Lists the estimated number of rows to be output by

the operation and passed on to the parent operation

Estimated Row Size—Indicates the estimated average row size of the rows being

passed through the operator

Estimated Subtree Cost—Lists the estimated cumulative total cost of this operation

and all child operations preceding it in the same subtree

Object—Indicates which database object is being accessed by the operation being

performed by the current node

Predicate—Indicates the search predicate specified for the object in the original

query

Seek Predicates—Indicates the search predicate being used in the seek against the

index when an index seek is being performed

Output List—Indicates which columns of data are being returned by the operation.

1305 Query Analysis in SSMS

Ordered—Indicates whether the rows are being retrieved via an index in sorted

order

Node ID—Lists a unique identifier of the node within the execution plan.

Some operators may also include the Actual Rebinds and Actual Rewinds counts When an

operator is on the outer side of a loop join, Actual Rebinds equals 1 and Actual Rewinds

equals 0 If an operator is on the inner side of a loop join, the sum of the number of

rebinds and rewinds should equal the number of rows returned by the table on the outer

side of the join A rebind means that one or more of the correlated parameters of the join

changed and the inner side must be reevaluated A rewind means that none of the

corre-lated parameters changed and the prior inner result set may be reused

NOTE

Depending on the type of operator and other query characteristics, not all the

preced-ing items are displayed in the ToolTip

The ToolTips for an execution plan generated when the query is actually executed display

the same information as the estimated execution plan, but the ToolTip also displays the

actual number of rows returned by the operation and the actual number of executions

This information is useful in determining the effectiveness of the statistics on the column

or index because it helps you compare how closely the estimated row count matches the

actual row count If a significant difference exists (significant being a relative term), you

might need to update the statistics and possibly increase the sample size used when the

statistics are updated to generate more accurate statistics

Figure 36.2 displays a sample ToolTip Notice the difference between the Estimated

Number of Rows value (8325.01) and the Actual Number of Rows value (160) This

indi-cates an obvious issue with missing or out-of-date statistics

NOTE

To achieve the large difference between the actual row count and estimated row count

shown in Figure 36.2, we disabled the AUTO-CREATE STATISTICS option for the

data-base If this option is not disabled, SQL Server automatically generates the missing

statistics on the ord_date column before generating the execution plan With the

col-umn statistics generated, it would likely come up with a better row estimate

In this example, the ToolTip displays the information for a Table Scan physical operation

The Estimated I/O Cost and Estimated CPU Cost provide critical information about the

relative performance of this query You want these numbers to be as low as possible

The Estimated Subtree Cost displays cumulated costs for this node and any previous nodes

that feed into it This number increases as you move from right to left in the execution

plan diagram For the next-to-last icon for a query execution path (the icon leading into

the statement icon), the ToolTip displays the Total Estimated Subtree Cost for the entire

query

NOTE

The total Estimated Subtree Cost displayed for the statement icon is the cost

com-pared against the query governor cost limit setting, if enabled, to determine whether

the query will be allowed to run For more information on configuring and setting the

query governor cost limit, see Chapter 35, “Understanding Query Optimization.”

The Predicate section outlines the predicates and parameters the query uses This

informa-tion is useful in determining how the Query Optimizer is interpreting your search

argu-ments (SARGs) and if they are being interpreted as SARGs that can be optimized

effectively

Putting all the ToolTip information together provides the key to understanding each

oper-ation and its potential cost You can use this informoper-ation to compare various incarnoper-ations

of a query to determine whether changes to the query result in improved query plans and

whether the estimated values are consistent with actual values

ptg 1307

Query Analysis in SSMS

NOTE

If the Query Optimizer has issued a warning about one of the execution plan operators,

such as missing column statistics or missing join predicates, the icon is displayed with

a yellow warning triangle (see Figure 36.3) These warnings indicate a condition that

can cause the Query Optimizer to choose a less efficient query plan than otherwise

expected The ToolTip for the operation with the warning icon includes a Warnings item

that indicates why the warning was generated

If you prefer to view the information about a node in an execution tree in more detail and

with something more stable than a ToolTip, you can right-click the node and select

Properties This brings up the Properties window, as shown in Figure 36.4

The Properties window provides all the same information available in the ToolTip and also

provides some more detailed information, along with descriptions of the types of

informa-tion provided

NOTE

For more examples of graphical execution plans, see Chapter 35 The sections that

dis-cuss the different query strategies contain examples of the graphical showplans that

correspond to the strategies Many of these showplans provide various examples of

the operator icons discussed in this section

Logical and Physical Operator Icons

If you want to better understand the graphical execution plans displayed in SSMS, it helps

to be able to recognize what each of the displayed icons represents Recognizing them is

especially valuable when you need to quickly locate operations that appear out of place

for the type of query being executed The following sections cover the more common

logical and physical operators displayed in the Query Analyzer execution plans

Assert

Assert is used to verify a condition, such as referential integrity (RI) or check constraint, or

to ensure that a scalar subquery returns only a single row It acts as sort of a roadblock,

allowing a result stream to continue only if the check being performed is satisfied The

argument displayed in the Assert ToolTip spells out each check being performed

For example, a deletion from the titles table in the bigpubs2008 database has to be

veri-fied to ensure that it doesn’t violate referential integrity with the sales and titleauthors

table The reference constraints need to check that the title_id being deleted does not

exist in either the sales or titleauthors tables If the result of the Assert returns a NULL,

the stream continues through the query Figure 36.5 shows the estimated execution plan

and ToolTip of the Assert that appears for a delete on titles The Predicate indicates that

the reference constraint rejects any case in which the matching foreign key expression

that returns from both child tables is NOT NULL Notice that it returns a different value (0

1309 Query Analysis in SSMS

or 1), depending on the table on which the foreign key violation occurs so that the

appropriate error message can be displayed

Clustered Index Delete , Insert , and Update

The Clustered Index physical operators Delete, Insert, and Update indicate that one or

more rows in the specified clustered index are being deleted, inserted, or updated The

index or indexes affected by the operation are specified in the Object item of the ToolTip

The Predicate indicates which rows are being deleted or which columns are being updated

Nonclustered Index Delete , Insert , and Update

Similar to the Clustered Index physical operators Delete, Insert, and Update, the

Nonclustered Index physical operators Delete, Insert, and Update indicate that one or

more rows in the specified nonclustered index are being deleted, inserted, or updated

Clustered Index Scan and Seek

A Clustered Index Seek is a logical and physical operator that indicates the Query

Optimizer is using the clustered index to find the data rows via the index pointers A

Clustered Index Scan (also a logical and physical operator) indicates whether the Query

Optimizer is scanning all or a subset of the table or index rows Note that a table scan

against a table with a clustered index displays as a Clustered Index Scan; the Query

Optimizer is performing a full scan against all data rows in the table, which are in

clus-tered key order

Figure 36.6 shows a Clustered Index Seek ToolTip The ToolTip indicates that the seek is

being performed against the UPK_Storeid index on the stores table The Seek Predicates

item indicates the search predicate being used for the lookup against the clustered index,

and the Query Optimizer determines that the results will be output in clustered index

order, as indicated by the Ordered item indicating true

Nonclustered Index Scan and Seek

A Nonclustered Index Seek is a logical and physical operator that indicates the Query

Optimizer is using the nonclustered index to find the data rows via the index pointers A

Nonclustered Index Scan (also a logical and physical operator) indicates whether the

Query Optimizer is scanning all or a subset of the nonclustered index rows The Seek

Predicates item in a Nonclustered Index Seek operator identifies the search predicate being

used for the lookup against the nonclustered index The Ordered item in the ToolTip

indi-cates true if the rows will be returned in nonclustered index key order

Collapse and Split

A Split physical and logical operator indicates that the Query Optimizer has decided to

break the rows’ input from the previous update optimization step into a separate delete

and insert operation The Estimated Number of Rows in the Split icon ToolTips is

normally double the input row count, reflecting this two-step operation If possible, the

1311 Query Analysis in SSMS

Query Optimizer might choose later in the plan to collapse those rows, grouping by a key

value The collapse typically occurs if the query processor encounters adjacent rows that

delete and insert the same key values

Compute Scalar

The Query Optimizer uses the Compute Scalar operator to output a computed scalar value

This value might be returned in the result set or used as input to another operation in the

query, such as a Filter operator You might see this operator when data values that are

feeding an input need to be converted to a different data type first

Concatenation [

The Concatenation operator indicates that the result sets from two or more input sources

are being concatenated into a single output You often see this when a UNION ALL is being

used You can force a concatenation union strategy by using the OPTION clause in the

query and specifying a CONCAT UNION Optimization of UNION queries, with examples of

the execution plan outputs, is covered in Chapter 35

Constant Scan

The Constant Scan operator introduces one or more constant rows into a query A

Compute Scalar operation sometimes is used to provide input to the Constant Scan

opera-tor A Compute Scalar operator often follows a Constant Scan operator to add columns to

any rows produced by the Constant Scan operator

Deleted Scan and Inserted Scan

The Deleted Scan and Inserted Scan icons in the execution plan indicate that a trigger is

being fired and that within that trigger, the Query Optimizer needs to scan either the

deleted or inserted tables

Filter

The Filter icon indicates that the input rows are being filtered according to the predicate

indicated in the ToolTip This operator is used primarily for intermediate operations that

the Query Optimizer needs to perform

Hash Match

Hash joins are covered in more detail in Chapter 35, but to understand the Hash Match

physical operator, you must understand the basic concept of hash joins to some degree

In a hash join, the keys common between the two tables are hashed into a hash bucket,

using the same hash function This bucket usually starts out in memory and then moves

to disk as needed The type of hashing that occurs depends on the amount of memory

required Hashing is commonly used for inner and outer joins, intersections, unions, and

differences The Query Optimizer often uses hashing for intermediate processing

A hash join requires at least one equality clause in the predicate, which includes the

clauses used to relate a primary key to a foreign key Usually, the Query Optimizer selects

a hash join when the input tables are unsorted or are different in size, when no

priate indexes exist, or when specific ordering of the result is not required Hash joins

help provide better query performance for large databases, complex queries, and

distrib-uted tables

A hash match operator uses the hash join strategy and might also include other criteria to

be considered a match The other criteria are indicated in the Probe Residual clause

shown in the Hash Match ToolTip

Nonclustered Index Spool , Row Count Spool , and Table Spool

An Index Spool, Row Count Spool, or Table Spool icon indicates that the rows are being

stored in a hidden spool table in the tempdb database, which exists only for the duration

of the query Generally, this spool is created to support a nested iteration operation

because the Query Optimizer might need to use the rows again If the operator is rewound

(for example, by a Nested Loops operator) but no rebinding is needed, the spooled data is

used instead of rescanning the input data

Often, you see a Spool icon under a Nested Loops icon in the execution plan A Table

Spool ToolTip does not show a predicate because no index is used An Index Spool ToolTip

shows a SEEK predicate A temporary work table is created for an index spool, and then a

temporary index is created on that table These temporary work tables are local to the

connection and live only as long as the query

The Row Count Spool operator counts how many rows are present in the input and

returns just the number of rows This operator is used when checking for the existence of

rows, rather than the actual data contained in the rows (for example, an existence

subquery or an outer join when the actual data from the inner side is not needed)

Eager Spool or Lazy Spool

The Query Optimizer selects to use either an Eager or Lazy method of filling the spool,

depending on the query The Eager method means that the spool table is built all at once

upon the first request for a row from the parent operator The Lazy method builds the

spool table as a row is requested by its parent operator

Log Row Scan

The Log Row Scan icon indicates that the transaction log is being scanned

Merge Join

The merge join is a strategy requiring that both the inputs be sorted on the common

columns, defined by the predicate The Merge Join operator may be preceded by an

explicit sort operation in the query plan A merge join performs one pass through each

input table, matching the columns defined in the WHERE or JOIN clause as it steps through

each input A merge join looks similar to a simple nested loop but uses only a single pass

of each table Occasionally, you might see an additional sort operation prior to the merge

join operation when the initial inputs are not sorted properly Merge joins are often used

to perform inner joins, left outer joins, left semi-joins, left anti-semi-joins, right outer

joins, right semi-joins, right anti-semi-joins, and union logical operations

1313 Query Analysis in SSMS

Nested Loops

Nested loop joins are also known as nested iteration Basically, in a nested iteration, every

qualifying row in the outer table is compared to every qualifying row in the inner table

This is why you may at times see a Spool icon of some sort providing input to a Nested

Loop icon This allows the inner table rows to be reused (that is, rewound) When every

row in each table is being compared, it is called a nạve nested loops join If an index is

used to find the qualifying rows, it is referred to as an index nested loops join Nested

loops can be used to perform inner joins, left outer joins, left semi-joins, and left

anti-semi-joins

The number of comparisons performed for a nested loop join is the calculation of the

number of outer rows times the estimated number of matching inner rows for each

lookup This can become expensive Generally, a nested loop join is considered to be most

effective when both input tables are relatively small

Parameter Table Scan

The Parameter Table Scan icon indicates that a table is acting as a parameter in the current

query Typically, this icon is displayed when INSERT queries exist in a stored procedure

Remote Delete , Remote Insert , Remote Query , Remote Scan ,

and Remote Update

The Remote Delete, Remote Insert, Remote Query, Remote Scan, and Remote Update

oper-ators indicate that the operation is being performed against a remote object such as a

linked table

RID Lookup

The RID Lookup operator indicates that a bookmark lookup is being performed on a heap

table using a row identifier (RID) The ToolTip indicates the bookmark label used to look up

the row and the name of the table in which the row is being looked up The RID Lookup

operator is always accompanied by a Nested Loop Join operator

Sequence

The Sequence operator executes each operation in its child node, moving from top to

bottom in sequence, and returns only the end result from the bottom operator You see

this most often in the updates of multiple objects

Sort

The Sort operator indicates that the input is being sorted The sort order is displayed in

the ToolTip’s Order By item