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

Nielsen c64.tex V4 - 07/21/2009 4:08pm Page 1352 Part IX Performance Tuning and Optimization In a sense, SQL Server has had filtered indexes since SQL Server 2000 with indexed view. There no rea- son why an indexed view couldn’t have included a WHERE clause and included data from a filtered set of rows; but filtered indexes are certainly easier to create than indexed views, and they function as nor- mal non-clustered indexes, which is an excellent segue into the next topic, indexed views. Indexed views For strictly OLTP operations (insert, update, delete, small selects), I firmly believe that a purely normalized design performs best. However, for reporting, analysis, and selecting large complex queries, a solution that denormalizes and pre-aggregates data is the answer. When the denormalized and pre-aggregated data needs to be real-time, an excellent alternative to base tables includes indexed views — a custom designed clustered index that is updated when the base tables are modified and can serve as a materialized view to denormalize and pre-aggregate data. Instead of building tables to duplicate data and denormalize a join, a view can be created that can join the two original tables and include the two source primary keys and all the columns required to select the data. Building a clustered index on the view then physically materializes every column in the select column list of the view. The resulting indexed view is in effect a custom multiple-table covering index. Although indexed views build on normal views, they should not be confused. A normal view is nothing more than a saved SELECT statement — no data is physically stored, as explained in Chapter 14, ‘‘Projecting Data Through Views.’’ Indexed views actually store the data on disk. An indexed view is Microsoft’s terminology for a materialized view. Numerous restrictions exist on indexed views, including the following: ■ The ANSI null and quoted identifier must be enabled when the view is created, and when any connection attempts to modify any data in the base tables. ■ The index must be a unique clustered index; therefore, the view must produce a unique set of rows without using DISTINCT. ■ The tables in the view must be tables (not nested views) in the local database and must be referenced by means of the two-part name ( schema.table). ■ The view must be created with the option WITH SCHEMABINDING. Because indexed views require schema binding, they can’t be mixed with table partition switching or rolling partitions. To switch a table partition, you must drop the indexed view, perform the switch, and then rebuild the indexed view. As an example of an indexed view being used to denormalize a large query, the following view selects data from the Product, WorkOrder,andScrapReason tables to produce a view of scrapped products: USE OBXKites; SET ANSI_Nulls ON; SET ANSI_Padding ON; SET ANSI_Warnings ON; 1352 www.getcoolebook.com Nielsen c64.tex V4 - 07/21/2009 4:08pm Page 1353 Indexing Strategies 64 SET ArithAbort ON; SET Concat_Null_Yields_Null ON; SET Quoted_Identifier ON; SET Numeric_RoundAbort OFF; GO CREATE VIEW vScrap WITH SCHEMABINDING AS SELECT WorkOrderID, P.NAME AS Product, P.ProductNumber, S.NAME AS ScrappedReason, ScrappedQty FROM Production.WorkOrder W JOIN Production.Product P ON P.ProductID = W.ProductID JOIN Production.ScrapReason S ON W.ScrapReasonID = S.ScrapReasonID With the view in place, the index can now be created on the view, resulting in an indexed view: CREATE UNIQUE CLUSTERED INDEX ivScrap ON vScrap (WorkOrderID, Product, ProductNumber, ScrappedReason, ScrappedQty) ; Indexed views can also be listed and created in Management Studio under the Views ➪ Indexes node. To drop an indexed view, the DROP statement must refer to the view instead a table: DROP INDEX ivscrap ON dbo.vScrap Dropping the view will automatically drop the indexed view created from the view. An advanced application of indexed views leverages the fact that an indexed view is a clustered index. It’s possible to build non-clustered indexes on the indexed view’s clustered index to create some pretty wild covering indexes. Indexed Views and Queries When SQL Server’s Query Optimizer develops the execution plan for a query, it includes the indexed view’s clustered index as one of the indexes it can use for the query, even if the query doesn’t explicitly reference the view. This only happens with Enterprise Edition, which is only a very last resort if a suit- able plan is not found. Often a suitable plan is found and the indexed view is never considered. More often than not you have to force the indexed view using the WITH (NOEXPAND) option. This means that the indexed view’s clustered index can serve as a covering index to speed queries. When the Query Optimizer selects the indexed view’s clustered index, the query execution plan indicates it with an index scan. Both of the following queries use the indexed view: SELECT WorkOrderID, P.NAME AS Product, 1353 www.getcoolebook.com Nielsen c64.tex V4 - 07/21/2009 4:08pm Page 1354 Part IX Performance Tuning and Optimization P.ProductNumber, S.NAME AS ScrappedReason, ScrappedQty FROM Production.WorkOrder W JOIN Production.Product P ON P.ProductID = W.ProductID JOIN Production.ScrapReason S ON W.ScrapReasonID = S.ScrapReasonID SELECT * FROM vScrap While indexed views are essentially the same as they were in SQL Server 2000, the Query Optimizer can now use indexed views with more types of queries. Best Practice J ust adding indexed views without fully analyzing how the queries use them may hurt performance more than it helps. As with any index, SQL Server must work to keep them correct with inserts, updates, or deletes. All index updates must take place within the transaction. If updating a single row in a base table must update hundreds of rows in the indexed view, or updating a row in the base table must force SQL Server to recalculate an aggregate query in an indexed view that draws from thousands of rows, there will be a performance cost. However, if real-time data is required, this still may be the best solution. Updating indexed views As with any denormalized copy of the data, the difficulty is keeping the data current. Indexed views have the same issue. As data in the underlying base tables is updated, the indexed view must be kept in sync. This process is completely transparent to the user and is more of a performance consideration than a programmatic issue. Summary The third layer of Smart Database Design, (in Chapter 2, ‘‘Data Architecture’’), is indexing. To intelli- gently create indexes you need to understand not only the technologies — the Query Optimizer, index pages, and indexing options — but also both your schema and your queries inside out. Indexing is essentially a bridge from the query to the data. While indexes can’t fully overcome a poor schema or poorly written queries, a database without good indexing is sure to perform poorly. To highlight the key ideas about indexing: ■ There’s no such thing as a table in SQL Server, only indexes — some with more data than others at the leaf level. ■ Clustered indexes store all the data of the base table, logically organized by the index keys. 1354 www.getcoolebook.com Nielsen c64.tex V4 - 07/21/2009 4:08pm Page 1355 Indexing Strategies 64 ■ Non-clustered indexes are subsets of data with their own keys and optionally included columns. ■ A non-clustered index that completely solves the query without having to jump over to the clustered index (using a bookmark lookup) is referred to as a covering index. ■ Bookmark lookups are the crux of indexing. For the queries that consume the most CPU dura- tion, avoid them with clustered indexes or covering indexes. For the other queries, bookmark lookups are the preferable method to reduce the number of indexes. ■ Filtered non-clustered indexes include only a small subset of rows, are faster to maintain, and can make perfect covering indexes. ■ Indexed views are custom indexes that actually materialize data and can pull from multiple base tables or pre-aggregate data. The next chapter continues the theme of understanding SQL Server internals and pragmatically using that knowledge to leverage performance from the system. 1355 www.getcoolebook.com Nielsen c64.tex V4 - 07/21/2009 4:08pm Page 1356 www.getcoolebook.com Nielsen c65.tex V4 - 07/21/2009 4:10pm Page 1357 Query Plan Reuse IN THIS CHAPTER Compiling SQL Working with the query Plan Cache C SC 101 taught that programming languages are either compiled or interpreted. SQL is neither. A SQL query is declarative, meaning that the SQL statement describes the question but does not specifically code how to best solve the problem. The best solution has to consider the available indexes and the mix of the data compared to the query parameters, and the hardware constraints. The indexes, data mix, and parameters are bound to fluctuate, so generating a query execu- tion plan (also called compiling the SQL query) when the query is created would be foolish. On the other hand, the process of generating a query execution plan can be expensive, sometimes more expensive than performing the query, so it doesn’t make sense to generate the query execution plan every time the query is executed. As a compromise, SQL Server generates a query execution plan the first time the query is executed and then stores that query execution plan in memory. The next time the same query is executed, SQL Server uses the stored query execution plan instead of generating a new plan. Query Compiling When SQL Server compiles a query, it’s stored in the Plan Cache, a portion of memory reserved for query plans, where it stays for a while, ready to be used again. SQL Server compiles both SQL queries and stored procedures into query execution plans. 1357 www.getcoolebook.com Nielsen c65.tex V4 - 07/21/2009 4:10pm Page 1358 Part IX Performance Tuning and Optimization The Query Optimizer The technology that compiles a SQL query is commonly called the Query Optimizer — the magic that makes SQL Server scream. But in fact, there are several components and stages to compiling a query. First, the parser dissects the T-SQL code, ensures that it is valid, and generates a parse tree, a logical representation of the query broken down into a sequence. Second, the Algebrizer attempts to simplify any arguments, and resolves any object names and aliases, identifies any data type conversions required, and binds any aggregate functions (e.g., group by, count(*)). The result is a query processor tree — a corrected version of the parse tree ready for the Query Optimizer. Delayed name resolution means that SQL Server will allow a stored procedure to be created even if the objects it references don’t yet exist. The idea is that the object might be created by the time the code is executed. Objects aren’t physically checked until the Algebrizer checks for them. Best Practice D elayed name resolution is one more reason why a simple parse check is insufficient when developing SQL code. Unit testing against sample data that exercises every use case, including dynamically created objects, is the only way to fully test any SQL code. The Query Optimizer will generate several possible query execution plans to solve the query and eval- uate them according to the estimated cost. The estimated cost isn’t a concrete figure that correlates to actual execution time but a relative cost in order to choose the best operation. The cost per operation also considers the amount of data, available indexes, and the data statistics to determine the best oper- ation to read the data. The Query Optimizer must also determine the best order in which to read the data sources and the best join operators to combine the data. The job of the Query Optimizer is to guess the amount of data that will be required by and produced by each operation and then plan the best operations for that amount of data. Once the query execution plan is generated, SQL Server will store it in the Plan Cache and inform the query processor that the plan is ready to b e executed. Chapter 63, ‘‘Interpreting Query Execution Plans,’’ has more details on reading and viewing the plans and interpreting the query operations within the plans. Viewing the Plan Cache There are dynamic management views (DMVs) that expose the Plan Cache. You can look at the query Plan Cache to verify that the query is in fact cached. The procedure cache can be large. While it’s not recommended in a production environment, clearing the cache will make checking for a specific query easier: DBCC FREEPROCCACHE 1358 www.getcoolebook.com Nielsen c65.tex V4 - 07/21/2009 4:10pm Page 1359 Query Plan Reuse 65 To examine the procedure cache, use the sys.dm_exec_cached_plans DMV, which returns the plan handle, which can be passed to sys.dm_exec_sql_text(plan_handle) and sys.dm_exec_ query_plan(plan_handle) to view the original SQL code and the query execution plan, as shown in Figure 65-1. FIGURE 65-1 Viewing the Plan Cache is easy with a few DMVs. The SQL source is right t here, and the query execution plan can be viewed by clicking on the XML in the query_plan column. Plan lifetime All the query plans in memory stay in the Plan Cache until SQL Server experiences ‘‘memory pressure’’ — softie speak for when the Plan Cache becomes about 75% full. Then SQL Server begins to age-out query plans based on how much time has elapsed since they were last executed and how complex they are. A complex query plan with a high query cost will stay in memory much longer than a simple query that was easy to compile. Query plan execution When the query processor needs to execute a query, it first checks to see whether the query can reuse a query execution plan already in the Plan Cache. It’s much faster to find and reuse a query execution 1359 www.getcoolebook.com Nielsen c65.tex V4 - 07/21/2009 4:10pm Page 1360 Part IX Performance Tuning and Optimization plan than to generate a new plan. In order to use a plan from the Plan Cache, the query must use qualified object names ( schema.object). If the query qualifies, then the query processor will search the Plan Cache for an identical SQL statement (minus parameters). If a match is found, then an execution context is used to hold the data and variables for that instance of the query execution plan. This enables multiple users to execute the same query execution plan simultaneously. Query Recompiles Because the query execution plan is based on a combination of the SQL query, the indexes, and the data, a number of changes might cause SQL Server to decide the query plan is no longer valid, or no longer the best possible plan. SQL Server then marks the query execution plan as unusable and generates a new query execution plan the next time it is executed. Single-statement query recompiles will simply cause the query to recompile the next time it is executed, but stored procedures will recompile mid-stream. The most common causes of an automatic recompile are as follows: ■ Out of date statistics can cause poor plans; therefore, if statistics for data referenced by the query are updated, SQL Server will stop and recompile based on the newer statistics. ■ A large change in the number of rows in the base table referenced by the query, even rows inserted by a trigger ■ Mixing DML statements and DDL statements in a stored procedure will cause a recompile. For example, creating a temp table, then running an update, then creating another temp table will force a recompile of the stored procedure following the second temp table’s creation. ■ A table, view, or index referenced by the query is altered. Therefore, if the stored proce- dure batch creates any temp tables, create them all at the beginning of the stored procedure or batch. Query recompilation was a greater problem with SQL Server 2000 and earlier, which would recompile the entire batch or stored procedure. Fortunately, beginning with SQL Server 2005, individual state- ments can be recompiled, rather than whole batches. This means that recompiles are less costly, even if they occur more frequently. The Sp_recompile object system stored procedure will force a recompile of any query plan stored that references that object (be it a stored procedure, a table, or a view) the next time the query is executed. Recompiles may be monitored using SQL Profiler using the SQL:StmtRecompile event. Ignore the SP:Recompile event — it offers incomplete information. A stored procedure can be created with the recompile options, which forces SQL Server to recompile it every time it’s executed. DBCC FreeProcCache clears out the procedure cache, so any queries that are reissued must be compiled again. 1360 www.getcoolebook.com Nielsen c65.tex V4 - 07/21/2009 4:10pm Page 1361 Query Plan Reuse 65 This chapter has presented the query execution plan default behavior, which is perfect for nearly all situations. I plan on updating this chapter with additional information on control- ling the query execution plan for those rare exceptions when the Query Optimizer needs help. Watch www.sqlserverbible.com or subscribe to the SQL Server Bible eNewsletter to download the updated chapter. Summary The heart of SQL Server is the Query Optimizer, the technology that analyzes the query, the indexes, and the data to compile the best query execution plan for that query for that moment. The best way to optimize queries is to provide the Query Optimizer with the best indexing. From there, SQL Server will handle the rest. The next chapter moves from single-user queries to multi-user contention and scalability and deals with transactions, isolation, and the ACID test. For some, the next topic is considered one of the harder top- ics in the database world, but I think it’s foundational to developing SQL Server databases. My goal is to carefully walk you through the different scenarios, so that you too will fully grok transactions. 1361 www.getcoolebook.com . Optimizer needs help. Watch www.sqlserverbible.com or subscribe to the SQL Server Bible eNewsletter to download the updated chapter. Summary The heart of SQL Server is the Query Optimizer, the. Compiling When SQL Server compiles a query, it’s stored in the Plan Cache, a portion of memory reserved for query plans, where it stays for a while, ready to be used again. SQL Server compiles both SQL. combination of the SQL query, the indexes, and the data, a number of changes might cause SQL Server to decide the query plan is no longer valid, or no longer the best possible plan. SQL Server then