ptg 1304 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. CHAPTER 36 Query Analysis Download from www.wowebook.com ptg 1305 Query Analysis in SSMS 36 . 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 dif feren ce betwee n 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. Download from www.wowebook.com ptg 1306 FIGURE 36.2 A ToolTip example. 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 information to compare various incarnations 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. CHAPTER 36 Query Analysis Download from www.wowebook.com ptg 1307 FIGURE 36.3 An example of an execution plan with warnings. Query Analysis in SSMS 36 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. Download from www.wowebook.com ptg 1308 CHAPTER 36 Query Analysis FIGURE 36.4 The query execution plan node properties. 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 Download from www.wowebook.com ptg 1309 Query Analysis in SSMS 36 FIGURE 36.5 An Assert example. 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 Download from www.wowebook.com ptg 1310 CHAPTER 36 Query Analysis FIGURE 36.6 Clustered Index Seek ToolTip example. 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 Download from www.wowebook.com ptg 1311 Query Analysis in SSMS 36 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 appro- Download from www.wowebook.com ptg 1312 CHAPTER 36 Query Analysis 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. Download from www.wowebook.com ptg 1313 Query Analysis in SSMS 36 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 naï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. Download from www.wowebook.com . 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. 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