Hướng dẫn học Microsoft SQL Server 2008 part 136 pptx

Nielsen p09.tex V4 - 07/21/2009 4:06pm Page 1312 www.getcoolebook.com Nielsen c63.tex V4 - 07/21/2009 4:04pm Page 1313 Interpreting Query Execution Plans IN THIS CHAPTER The language of performance tuning and optimization Viewing, saving, and working with query execution plans Reading query execution operators I believe that intelligence is the ability to abstract — to create something new at a higher lever based on more primitive constructs. The ability to express thoughts using words composed of letters and simple sounds is abstraction; to turn beats and notes into a melody is abstraction; and to turn 1s a 0s in CPU registers into a programming language and then use that language to develop an application represents multiple layers of abstraction. Interpreting SQL Server query execution plans is abstraction inside-out. SQL, as a declarative language, is an interesting study of abstraction because the underlying primitive operations that execute the query are dynamically determined based on more than just the SQL query. The art of SQL Server performance tuning and optimization (PTO) is essentially the skill of reading the query execution plans and understanding how to manipulate the factors that determine the physical operations in an effort to improve performance. The operations inside a query execution plan are the language of SQL Server PTO, which is why this part of the book begins with reading and interpreting the query execution plan. Viewing Query Execution Plans The SQL Server development team has exposed the query execution plan in sev- eral places and in several formats, making it easy to find, view, and work with query execution plans: ■ Management Studio’s Query Editor can display the estimated or actual query execution plan as a graphic or as XML. ■ Showplans return the query plan as a message or a result set. 1313 www.getcoolebook.com Nielsen c63.tex V4 - 07/21/2009 4:04pm Page 1314 Part IX Performance Tuning and Optimization ■ SQL Profiler can capture the query execution plan as plain text or as XML that can be viewed in graphic form. ■ Query plans in cache may be viewed using dynamic management views. Additionally, the query execution plan can be saved as an XML file and opened later using Management Studio’s Query Editor. What’s New with Query Execution Plans? T here’s very little that’s new regarding viewing query execution plans, but there are a few new tricks to working with query execution plans in SQL Server 2008: ■ Management Studio’s Query Editor can switch the graphical query execution plan into XML from the context menu. ■ A saved query execution plan now includes the full query, so when it’s re-opened, the original source query can be viewed in the Query Editor. ■ The XML query execution plan is formatted better. ■ The Query Editor can now open the XML query execution plan that’s returned from the sys.dm_exec_query_plan()dynamic management function as a graphical plan with a single click. Estimated query execution plans SQL Server can return just the estimated query execution plan before the query is executed, or it can return the actual query execution plan with the results of the query. The difference between the estimated and the actual isn’t the plan — the sequence of logical and physical operations is identical; the only difference is the estimated vs. actual number of rows returned by each operation. Before the query is executed, the Query Optimizer will estimate the number of rows based on statistics and use that estimate in determining the plan. After the query is executed, the query processor can add to the plan the actual number of rows processed by each operation. The estimated query execution plan may be viewed by selecting the query in the Query Editor and either clicking the Display Estimated Execution Plan button in the toolbar, selecting Query ➪ Display Estimated Execution Plan, or by pressing Ctrl+L. Because the query isn’t actually executed, the estimated query execution plan should display in the Execution Plan tab rather quickly. The Query Editor’s execution plan The data flow in a query plan is from right to left, bottom to top, as shown in Figure 63-1. Each operation is presented as an icon. The Query Editor isn’t just a static display: 1314 www.getcoolebook.com Nielsen c63.tex V4 - 07/21/2009 4:04pm Page 1315 Interpreting Query Execution Plans 63 ■ Mousing over the logical operation causes a dialog to appear containing detailed information about the logical operation, including the logical cost and the portion of the query handled by the operation. ■ Mousing over a connector line presents detailed information about how much data is being moved by that connector. ■ The Property window also presents detailed information about any operation or connector. The display may be zoomed or sized to fit using the right-click context menu. FIGURE 63-1 Query execution plans show the operations SQL Server uses to solve the query. To walk through the query execution plan shown in Figure 63-1: 1. In the upper-right corner of the plan, the index seek operation is finding every row with ProductID = 757 using an index seek operation against the [WorkOrder.IX_WorkOrder_ ProductID] non-clustered index. 1315 www.getcoolebook.com Nielsen c63.tex V4 - 07/21/2009 4:04pm Page 1316 Part IX Performance Tuning and Optimization 2. The nested loop operation receives every row from the index seek, and asks for those same rows from the clustered index, calling the key lookup operation. Just ignore the compute scalar operation, as it’s only handling a type conversion. 3. The nested loop assembles, or joins, the data from the index seek and key lookup and passes the data to the select operation, which returns the correct columns to the client. Note the following key pieces of information on the query plan: ■ The type of operation. Key operations are listed later in Table 63-1. ■ The object, listed below the operator and in the pop-up info box, is the actual index hit by the operation. ■ The estimated number of rows, as the Query Optimizer uses the estimated number of rows to choose the best query execution plan. ■ The estimated operator cost and the estimated subtree cost are relative values used by the Query Optimizer. When tuning a query, these are critical values to watch. I typically read the cost as cost times 1,000. For example, I’ll read .0051234 as 5, or .3255786 as 325, to make it easier to think through the plans. Plans can also be saved to a plan file ( .sqlplan) to be reexamined later. Re-opening a plan opens the graphical execution plan. The context menu has a new option to edit the SQL query, which opens the original SQL statement in a new Query Editor tab. Returning the plan with showplans In addition to the graphical execution plan, the Showplan options reveal the execution plan with some additional detail. Just as the display-estimated-execution-plan Query Editor option, when showplan is on, SQL Server will return the query execution plan but won’t execute the statement. SET SHOWPLAN must be the only statement in the batch. SET SHOWPLAN comesisthreeflavors:ALL, TEXT,andXML: ■ SHOWPLAN_ALL displays the operators as a result set. It exposes the same information as the graphical execution plan. The executing statement is returned in the first row and every operator is returned as subsequent rows. (This is a deprecated feature and will be eliminated in a future version.) ■ SHOWPLAN_TEXT is very similar to SHOWPLAN_ALL except that the executing statement and the operations are in separate result sets and only the stmt text (first column) is displayed. The SHOWPLAN_TEXT option, along with the SET STATISTICS options, may also be toggled graphically within Query Editor. Use the context menu’s Query Options command to open the Query Properties and you can find the showplan options by selecting Execution ➪ Advanced. (This is also a deprecated feature that will be eliminated in a future version.) ■ SHOWPLAN_XML displays more detail than any other method of viewing the execution plan, and it offers the benefit of storing and displaying unstructured data, so it can dis- play additional information that may not pertain to all execution plans. For example, in the <Statement> element, SHOWPLAN_XML displays the Query Optimizer optimization level, or the reason why the Query Optimizer returned this execution plan. For the XML version of 1316 www.getcoolebook.com Nielsen c63.tex V4 - 07/21/2009 4:04pm Page 1317 Interpreting Query Execution Plans 63 SHOWPLAN, the ‘‘Include actual execution’’ Query Editor option must be off. In addition, if the query results are set to grid, then the grid will offer a link to open the XML using the browser. Another way to gather the execution plan is the SET STATISTICS PROFILE ON command, which exe- cutes the query and then supplies the same detail as SHOWPLAN_ALL with the addition of actual row counts and execution counts. This is the result set equivalent of the SHOW ACTUAL execution plan. This is a deprecated feature, to be eliminated in a future version. SQL Profiler’s execution plans Within the Performance event category, SQL Server Profiler includes several showplan events. The Showplan XML event includes the XML for the query execution plan, which SQL Profiler displays in a graphical form. It includes the same features as the Query Editor to mouse over the operation to see more properties and zoom the display. Saving the plan is possible with SQL Profiler, but it’s well hidden: If you right-click anywhere in the upper pane on the line of a Showplan XML or Showplan XML Statistics Profile event, you can choose to ‘‘Extract Event Data.’’ This enables you to save the plan as a .sqlplan file. Cool add! Examining plans using dynamic management views Dynamic management views, or DMVs, previously introduced with SQL Server 2005, provide an excel- lent window into SQL Server’s internals. Three of the DMVs expose the query execution plans currently in the cache: ■ sys.dm_exec_cached_plans: Returns the plan type, memory size, and usecounts ■ sys.dm_exec_query_stats: Returns several aggregate execution statistics (e.g., last_execution_time, max_elapsed_time) ■ sys.dm_exec_requests: Returns plans that are currently executing Each of these DMVs returns a plan handle (a binary identifier of the query execution plan in memory) that can be passed to one of the following dynamic management functions with a CROSS APPLY to extract the query text or the query execution plan: ■ sys.dm_exec_query_plan(plan_handle): Returns the query execution plan in XML. Note that for some very complex queries, if the XML nesting level is greater than 128, this method of extracting the query plan will fail. Use the next method instead. ■ sys.dm_exec_text_query_plan(plan_handle): Returns the query execution plan as a text showplan ■ sys.dm_exec_sql_text(plan_handle): Returns the query SQL statement The code example in Figure 63-2 pulls together data from the DMVs to view the original SQL statements and query execution plans from the cache. 1317 www.getcoolebook.com Nielsen c63.tex V4 - 07/21/2009 4:04pm Page 1318 Part IX Performance Tuning and Optimization FIGURE 63-2 Using DMVs, it’s possible to view the SQL code and the query execution plan in the procedure cache. Clicking the XML in the right-most column opens another tab with a graphical view of the selected query execution plan. Interpreting the Query Execution Plan Reading query execution plans may seem difficult at first; there are several types of complex icons, a ton of detail, and the sheer scope of some query plans can be overwhelming. SQL server uses about 60 operators. Some represent specific physical tasks, while most logically represent a collection of hidden tasks. Table 63-1 lists the key operators regarding select queries and indexing. 1318 www.getcoolebook.com Nielsen c63.tex V4 - 07/21/2009 4:04pm Page 1319 Interpreting Query Execution Plans 63 TABLE 63-1 Query Execution Plan Operators Icon Definition Description Clustered index scan In a clustered index scan, SQL Server reads the entire clustered index, typically sequentially, but it can be otherwise depending on the isolation level and the fragmentation. SQL Server chooses this operation when the set of rows requested by the WHERE clause or join condition is a large percentage of rows needed from the table or no index is available to select the range. Table scan A table scan is similar to a clustered index scan but it scans a heap. Clustered index seek In a clustered index seek, SQL Server rapidly navigates the clustered index b-tree to retrieve specific rows. The benefit of the clustered index seek is that when the row(s) are determined, all the columns are immediately available. Hash match A hash match is an unordered join method that builds a temp table and iteratively matches with data from another table. A hash match is more efficient if one table is significantly larger than the other table. This is the worst-case join method and is used when no suitable index is available. Merge join The merge join is the fastest method of joining two tables if both tables are pre-sorted. Nested loop A nested loop iterates through the first table (or intermediate result set if in the middle of the query plan), finding matching row(s) in the second table for each row from the first. Typically, nested-loop joins are best when a large index is joined with a small table. Index scan (non-clustered ) In a non-clustered index scan, SQL Server reads through the entire index sequentially looking for the data. Index seek (non-clustered ) A non-clustered index seek navigates the b-tree index from the root node, through the intermediate node(s), to the leaf node, and finally to the row. The benefit of a nonclustered index seek is that it tends to be narrow (have few columns), so more rows can fit on a page. Once the correct row is identified, if all the required columns are found in the index, then the seek is complete because the index covers the needs of the query. If a range is required, an index seek operation can seek to the start of the range and then sequentially read to the end of the range. RID lookup The RID lookup locates rows in the data pages of a heap (a table without a clustered index). Typically, a RID lookup works with a nested loop to locate the data pages following a non-clustered index seek or scan. Filter In some situations, SQL Server retrieves all the data from a table and then uses filter operations to select the correct rows. Sometimes the Query Optimizer uses a Filter for performance reasons, but it’s more often due to the lack of a useful index. Sort In some situations SQL Server retrieves all the data from a table and then sorts the data to prepare it for operations to perform the ORDER BY. While the filters and sorts are themselves fast operations, they need to examine all the data, which means a slower scan is required. These typically indicate a lack of useful indexes. Spool In a spool operation, SQL Server has to save a temporary set of data. 1319 www.getcoolebook.com Nielsen c63.tex V4 - 07/21/2009 4:04pm Page 1320 Part IX Performance Tuning and Optimization Summary If you’re new to SQL Server performance tuning and optimization, the mechanics of reading a query execution plan can’t be underestimated. Fortunately, SQL Server exposes the internals of query execu- tion in several ways: graphically, with text showplans, and with XML, and makes them relatively easy to read once they make sense. This chapter covered the how-to of reading and working with query execution plans. The key point to remember is that both estimated and actual query execution plans show the actual plan. The difference is that the estimated plan doesn’t perform the query, so it can’t show the actual row count in the con- nector’s properties. The next chapter transitions into the whys and wherefores of query execution plans and how to manipu- late them with indexes — an execution plan one-two punch. 1320 www.getcoolebook.com Nielsen c64.tex V4 - 07/21/2009 4:08pm Page 1321 Indexing Strategies IN THIS CHAPTER Indexing for improving performance Interpreting query execution plans A database strategy for improving performance M y son Dave and I love to watch ‘‘MythBusters.’’ Even if we know Adam and Jamie aren’t going to get the pig’s head to blow up, it’s a blast to see them try. If there’s any aspect of SQL Server populated with misconceptions (or shall I say, ‘‘mythconceptions’’), it’s indexing — and that’s unfortunate, because sound indexing isn’t all that complicated. My Smart Database Design Seminar is based on the notion (described in Chapter 2) that an elegant physical schema lends itself to writing great set-based queries that respond well to indexing. It’s the theory I use when I design a database and when I go on a performance-tuning and optimization consulting job. One aspect of Smart Database Design is that no layer can overcome deficiencies in lower layers, i.e., no index will solve an inappropriate cursor and a sorry database schema. Nulltheless, indexes are at the heart of SQL Server performance; they are the bridge from the question to the data — from the query to the schema. Indexes are so critical to SQL Server performance that I’ve spent two months longer than my writing schedule allowed to explain how to think about indexes, work through the twelve query paths, and present a solid indexing strategy. Zen and the Art of Indexing Right up front, here’s my secret to designing effective indexes: When I’m index- ing, in my mind’s eye I don’t see tables and indexes, I see only indexes. Some indexes have more data attached to the leaf level than other indexes, but there are only indexes. When indexing, there’s no such thing as a table in SQL Server. 1321 www.getcoolebook.com . are the language of SQL Server PTO, which is why this part of the book begins with reading and interpreting the query execution plan. Viewing Query Execution Plans The SQL Server development team. a .sqlplan file. Cool add! Examining plans using dynamic management views Dynamic management views, or DMVs, previously introduced with SQL Server 2005, provide an excel- lent window into SQL Server s. clustered index scan, SQL Server reads the entire clustered index, typically sequentially, but it can be otherwise depending on the isolation level and the fragmentation. SQL Server chooses this