Understanding query execution plans
•Descargar como PPTX, PDF•
0 recomendaciones•415 vistas
Understanding query execution plans is something that a lot of IT professionals either don't know about or don't understand. SQL Server's programming language T-SQL is different from most other programming languages. In most languages you tell the language what you want it to do, in T-SQL you tell it what you want. This means you are at the mercy of the query optimiser which will take the logical instruction and convert it into a physical plan. The query execution plan is a map of what the optimiser thinks will be a good way of returning the data you have asked for. Being able to understand query plans and what they show is critical for both DBA's and developers in uncovering query performance problems. To view the webcast:http://dell.to/17k8zWK
Recomendados
Recomendados
Más contenido relacionado
Más de SQLDBApros
Más de SQLDBApros (8)
Último
Último (20)
Understanding query execution plans
- 1. Understanding Query Execution Plans Richard Douglas
- 2. 2 Global MarketingUnderstanding Query Execution Plans Agenda • Introductions • The Query Optimizer • Commonly used operators • Blocking and non-blocking operators • Reading Query Execution Plans
- 3. 3 Global MarketingUnderstanding Query Execution Plans Your host • Richard Douglas • Systems Consultant • SQL Server MCITPro • Maidenhead SQL User Group Leader • Blog: http://SQL.RichardDouglas.co.uk • Twitter: @SQLRich • Email: Richard.Douglas@Software.Dell.com
- 4. 4 Global MarketingUnderstanding Query Execution Plans Why do we need an optimizer? The Query Optimizer • T-SQL is a “What” not “how” language. • We write “logical” requests. • SQL Optimizer Engine converts logical requests into physical plans.
- 5. 5 Global MarketingUnderstanding Query Execution Plans The job of the SQL Optimizer is to find “the best plan possible”. The Query Optimizer What is the goal of the Optimizer?
- 6. 6 Global MarketingUnderstanding Query Execution Plans Query optimization explained simply 1. Query submitted 2. Magic happens 3. Shedload of data returned
- 7. 7 Global MarketingUnderstanding Query Execution Plans Optimizer steps Query Optimization (in a bit more detail) Bind Execute Optimize Parse
- 8. 8 Global MarketingUnderstanding Query Execution Plans Parse Builds a tree structure based upon the logical operators in the query. For example: SELECT SSOD.[SalesOrderID], PP.[Name], PP.[Weight], SSOD.[UnitPrice] FROM [Sales].[SalesOrderDetail] SSOD INNER JOIN [Production].[Product] PP ON SSOD.ProductID = PP.ProductID WHERE PP.Weight > 100 Project Filter Join Product Sales Order Detail LogicalOperations Nodes
- 9. 9 Global MarketingUnderstanding Query Execution Plans Bind • Series of validation steps • Schema validation • Table validation • Attribute validation • Permission validation SELECT SSOD.[SalesOrderID], PP.[Name], PP.[Weight], SSOD.[UnitPrice] FROM [Sales].[SalesOrderDetail] SSOD INNER JOIN [Production].[Product] PP ON SSOD.ProductID = PP.ProductID WHERE PP.Weight > 100
- 10. 10 Global MarketingUnderstanding Query Execution Plans Optimize Works though many rules and heuristics. These Include: • Commutativity • Substitution rules • Exploration rules • Implementation rules
- 12. 12 Global MarketingUnderstanding Query Execution Plans Statistics • SQL uses a cost based optimizer • Costs influenced by statistics
- 13. 14 Global MarketingUnderstanding Query Execution Plans Commonly used operators SELECT UPDATE INSERT DELETE Table scan Clustered Index Scan NonClustered Index Scan Clustered Index Seek NonClustered Index Seek Key Lookup Nested Loop Join Merge Join Hash Join
- 14. 15 Global MarketingUnderstanding Query Execution Plans Blocking and Non-blocking Operators • Operators / Iterators can be put in two categories: 1. Blocking 2. Non-blocking • Having a blocking operator in your plan means other operators further down the line are sitting idle. This will reduce the overall performance of your query • Some examples…
- 15. 16 Global MarketingUnderstanding Query Execution Plans Non-blocking example Blocking and Non-blocking operators • An example using a Compute Scalar function Compute Scalar Function Row 1 Row 2 Row 3 Row 4 Row 5 ?
- 16. 17 Global MarketingUnderstanding Query Execution Plans Blocking example Blocking and Non-blocking operators • An example using the sort operator: Row 1 Row 2 Row 3 Row 4 Row 5 ? Sort Desc
- 17. Demo’s
- 18. Pg. 22© 2012 Quest Software Inc. All rights reserved. Solution Area Product Description Fast, flexible backup and recovery with industry-leading compression technology Discover and resolve performance issues in production before they impact end users and service levels Deepest possible understanding of database performance and norms Plan and develop applications that deliver both functionality and optimal performance Project Lucy Backup and Recovery Performance & Operations Performance Tuning Development Comprehensive schema, object, security and change management Administration Community crowdsourcing for SQL Server tracing and performance information! Community, Knowledge, Training
- 19. SQLRelay Dates 11/11/13 – Reading 12/11/13 – Southampton 13/11/13 – Cardiff 14/11/13 – Birmingham 15/11/13 – Hemel Hempstead 25/11/13 – Newcastle 26/11/13 – Manchester 27/11/13 – Norwich 28/11/13 – Bristol 29/11/13 – London @SQLRelay2013
- 20. 24 Global MarketingUnderstanding Query Execution Plans Any questions?
- 21. Thank you for attending Richard Douglas Richard.Douglas@Software.Dell.com @SQLRich
Notas del editor
- Heuristics quote from WikiPedia - The objective of a heuristic is to produce quickly enough a solution that is good enough for solving the problem at hand. This solution may not be the best of all the actual solutions to this problem, or it may simply approximate the exact solution. But it is still valuable because finding it does not require a prohibitively long time.Commutativity – In mathematics Commutativity is where sums can be rewritten and still provide the same answer, 10+100=110 & 100+10=110.The optimizer knows that if you are asking for an inner join (that is a join where the same data must be found on either side) then it would be more efficient to join the large table to the smaller one. This would result in less work for the storage engine. Let’s take the figures 10 & 100 again Table A will be 100 records, table b will be 10.Join A to b would require 100 searches into table b. join b to a would require 10 searches into table a – quite a saving and still the same logical outcome.In other words this part helps to work out the most efficient join order for your query. It’s been some time since we have had to worry about the order of our joins, the optimizer now figures that out for us.Substitution rules &Exploration rules - Substitution &Exploration rules are rules that use heuristics or mathematic rules to generate new tree shapes, this may provide the opportunity for more optimization rules.Implementation rules - Implementation rules convert the logical trees into physical trees, at this point they can be optimized further and become the eventual execution plan.
- Physical OperatorsPhysical operators implement the operation described by logical operators. Each physical operator is an object or routine that performs an operation. For example, some physical operators access columns or rows from a table, index or view. Other physical operators perform other operations such as calculations, aggregations, data integrity checks or joins. Physical operators have costs associated with them.The physical operators initialize, collect data, and close. Specifically, the physical operator can answer the following three method calls:Init(): The Init() method causes a physical operator to initialize itself and set up any required data structures. The physical operator may receive many Init() calls, though typically a physical operator receives only one.GetNext(): The GetNext() method causes a physical operator to get the first, or subsequent row of data. The physical operator may receive zero or many GetNext() calls.Close(): The Close() method causes a physical operator to perform some clean-up operations and shut itself down. A physical operator only receives one Close() call.The GetNext() method returns one row of data, and the number of times it is called appears as ActualRows in the Showplan output that is produced by using SET STATISTICS PROFILE ON or SET STATISTICS XML ON. For more information about these SET options, see SET STATISTICS PROFILE (Transact-SQL) and SET STATISTICS XML (Transact-SQL).The ActualRebinds and ActualRewinds counts that appear in Showplan output refer to the number of times that the Init() method is called. Unless an operator is on the inner side of a loop join, ActualRebinds equals one and ActualRewinds equals zero. 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 processed 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 correlated parameters changed and the prior inner result set may be reused.ActualRebinds and ActualRewinds are present in XML Showplan output produced by using SET STATISTICS XML ON. They are only populated for the Nonclustered Index Spool, Remote Query, Row Count Spool, Sort, Table Spool, and Table-valued Functionoperators. ActualRebinds and ActualRewinds may also be populated for the Assert and Filter operators when the StartupExpression attribute is set to TRUE.When ActualRebinds and ActualRewinds are present in an XML Showplan, they are comparable to EstimateRebinds and EstimateRewinds. When they are absent, the estimated number of rows (EstimateRows) is comparable to the actual number of rows (ActualRows). Note that actual graphical Showplan output displays zeros for the actual rebinds and actual rewinds when they are absent.A related counter, ActualEndOfScans, is available only when Showplan output is produced by using SET STATISTICS XML ON. Whenever a physical operator reaches the end of its data stream, this counter is incremented by one. A physical operator can reach the end of its data stream zero, one, or multiple times. As with rebinds and rewinds, the number of end of scans can be more than one only if the operator is on the inner side of a loop join. The number of end of scans should be less than or equal to the sum of the number of rebinds and rewinds.