Maciej Pilecki Consultant Project Botticelli Ltd. DAT404.

Post on 19-Jan-2018

213 views 0 download

description

SELECT About FROM Speakers WHERE Name = ’Maciej Pilecki’ Over 10 years of SQL Server experience SQL Server MVP since Jan 2006 Specializing in SQL Server database development, administration, performance tuning and troubleshooting Delivering consulting services around the world (special discounted rate for TechEd attendees) Frequent speaker at many international conferences Living in Wroclaw, Poland

Transcript of Maciej Pilecki Consultant Project Botticelli Ltd. DAT404.

Masterclass: Microsoft SQL Server Execution Plans, from Compilation to Caching to Reuse

Maciej PileckiConsultantProject Botticelli Ltd.DAT404

SELECT About FROM SpeakersWHERE Name = ’Maciej Pilecki’

Over 10 years of SQL Server experienceSQL Server MVP since Jan 2006Specializing in SQL Server database development, administration, performance tuning and troubleshooting Delivering consulting services around the world (special discounted rate for TechEd attendees)Frequent speaker at many international conferencesLiving in Wroclaw, Poland

Agenda

Query optimization and executionPlan caching and reuseWhat is the Procedure Cache?Managing the Procedure CacheControlling plan reuse

Query Execution

You type your query in SSMS, hit F5 and get the results......well, it is more complicated than that...

Query Execution

Every query goes through a numer of steps:ParsingAlgebraizationOptimizationExecution

Query Optimization

Process of selecting one execution plan from many possible plansCost-based – aimed at finding execution plan with the lowest (or close to lowest) estimated execution cost

Source for graphics: SQL Server BOL

Can optimization go wrong?

Optimizer ESTIMATES the cost for each potential planThat estimate can be wrong (lack of stats, outdated stats, query structure etc.)A WRONG (sub-optimal) plan can be selected (but it seems best)You can outsmart the optimizer with hints! (if you have to)

Query Optimization

Query Optimization is good - improves query performanceBut:

It is expensive (memory, CPU, time)It is throttled at the server level (see Optimization section in KB 907877)It can timeout

We need plan caching...

Plan caching

Attempt to save the optimization effort by caching and reusing execution plansExecution plan consists of:

Query plan (one for many users, read-only)Execution context (per-user but cached and reused as well)

Plan cache is also called „Procedure Cache”

Query Execution PhasesQuery

Cache lookup

Compile query Schema

Statistics

Check plan

Plan valid?

Execute query

Found

Not found

Yes

No

How cache lookup worksFinding an existing plan is based on:

ID of the object (for SPs, triggers, functions etc.)Hash of the query text (for ad-hoc queries)

Also, the cache-key attributes must match:SET optionsDBIDLanguage and date settingsuser_id for non-qualified object namesAnd other...

Inside the Procedure CacheStores compiled execution plansThere is not one ProcCache but 4:

CACHESTORE_OBJCP – object plansCACHESTORE_SQLCP – SQL plansCACHESTORE_PHDR – „bound trees”CACHESTORE_XPROC – XProcs

ProcCache „steals” pages from the Buffer PoolEntries aged-out based on cost of compilation and usage frequency

Inside the Procedure Cache - DMVs

sys.dm_exec_cached_planssys.dm_exec_sql_text(plan_handle)sys.dm_exec_query_plan(plan_handle)sys.dm_exec_plan_attributes(plan_handle)sys.dm_exec_query_statsYou can combine and aggregate those in a number of interesting ways...

Procedure Cache SizeProcedure cache size limits

SQL 2000: max. 4GBSQL 2005 RTM and SP1:

75% 0-8GB + 50% 8-64GB + 25% >64GBSQL 2005 SP2 and SQL 2008:

75% 0-4GB + 10% 4-64GB + 5% >64GBExample: with 16GB on RTM limit is 10GB, on SP2: 4.2 GBOr number of items:

Up to 10007 per cache store (SQLCP, OBJCP) on 32-bitUp to 40009 per cache store on 64-bit

No direct control over the size of cacheWorkload Governor helps, if you can use it (EE only)

How is Procedure Cache Cleared?Automatically:

Entries aged-out due to memory pressureDue to certain database operations:

Database restore, changing DB state, etc.See KB917828 for SQL Server 2005 list (or http://blogs.msdn.com/sqlprogrammability/archive/2007/01/17/10-0-plan-cache-flush.aspx)

Logs to ERRORLOG: "SQL Server has encountered %d occurrence(s) of cachestore flush for the '%s' cachestore (part of plan cache) due to some database maintenance or reconfigure operations".Fixed in SQL 2008 (in most cases clears plans for one DB only)

How is Procedure Cache Cleared?Manually:

DBCC FREEPROCCACHEClears everything – everything needs to be recompiledUsually an overkill – serious performance effects

In SQL 2008 you can be more selective:DBCC FREEPROCCACHE ( { plan_handle | sql_handle | pool_name } )

plan_handle – single plansql_handle – all plans for particular SQL textpool_name – Resorce Governor pool

How is Procedure Cache Cleared?Manually (cont’d):

DBCC FLUSHPROCINDB(dbid)Clears all plans for a single databaseBetter but still an overkillUndocumented and unsupported

DBCC FREESYSTEMCACHE('SQL Plans')Clears a particular cache store In this case, the ad-hoc plans cache storeKeeps other plans intactUndocumented and unsupported

Managing plan reuse

Generally, plan reuse is a good thingLess plans in cache (less memory consumed)Less time spend optimizing and compiling plans

Our goal is to improve plan reuse as much as possible (but beware of drawbacks!)Depending on application, can be very easy or very hard to achieve

Controlling plan cachingApplication-side parameterizationStored ProceduresForced parameterization

Database-level optionMore aggressive in parameterizing ad-hoc SQL

Optimize for ad hoc workloadsNew server option in SQL Server 2008Only a stub is cached on first executionFull plan cached after second execution

When is plan reuse NOT a good thing?

The main downside of plan caching:Cached plan is based on the parameters used during optimizationKnown as „parameter sniffing”Not always the best plan for subsequent executions with a different parameter valuesSometimes difficult to spot – look for queries with greatly varying execution statsEstimated number of rows << Actual number of rows

Working around the „bad plan” issue

Recompiling for given execution:OPTION (RECOMPILE)EXECUTE ... WITH RECOMPILE

Always recompiling (for SPs) Masking parameter values through local variablesSpecifying value for the optimizer:

OPTIMIZE FOR (@var = val)OPTIMIZE FOR UNKNOWN (new in 2008)

Summary

Query optimization and executionPlan caching and reuseWhat is the Procedure Cache?Managing the Procedure CacheControlling plan reuse

Additional reading:http://msdn.microsoft.com/en-us/library/ee343986.aspx

question & answerEmail: maciej@projectbotticelli.com

www.microsoft.com/teched

Sessions On-Demand & Community

http://microsoft.com/technet

Resources for IT Professionals

http://microsoft.com/msdn

Resources for Developers

www.microsoft.com/learning

Microsoft Certification & Training Resources

Resources

Complete an evaluation on CommNet and enter to win an Xbox 360 Elite!

© 2009 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS,

IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.