Things You Can Find in the Plan Cache

A Few Words about Me… @MatanYungman MadeiraData.com SQLServerRadio.com Image courtesy of Mister GC / FreeDigitalPhotos.net

Agenda What is the Plan Cache Ways to explore it And what we can find while exploring How to successfully leverage it Querying it to identify problematic queries Querying Execution Plan XML

Query Pre - Execution Phases Optimize Bind Parse Parser: Verifies syntax and creates a tree called parse tree that represents the query Algebrizer: Its role is to understand what the query wants to do. understands which alias refers to each table, expands objects and so on. Builds a query tree that explains what the query wants to do at the end and passes on. Optimizer:

The Process Is Expensive Query Execution Time CPU Memory The Solution: Save Plan for Future Reuse 1. Memory – there is a cost to generate and use the plan. Show fingerprint in the scripts

Our Mission: Maximize Reuse While Fixing The Cases Where Reuse Is Not Good

The Plan Cache Built from 4 cache stores CACHESTORE_OBJCP – Object Plans CACHESTORE_SQLCP – Ad hoc and Prepared Plans CACHESTORE_PHDR – Bound Trees CACHESTORE_XPROC – Extended Procedures “Steals” its memory from the buffer pool Each store is basically a hash table Age-out algorithm Explain what is a prepared statement Prepated statement = parameterized statement Hash Table - a structure that can map keys to values. A hash table uses a hash functionto compute an index into an array of buckets or slots, from which the correct value can be found.

Diving In – Views sys.dm_exec_cached_plans sys.dm_exec_query_stats One row per batch Use counts Object type, Cache object type Plan_handle sys.dm_exec_query_stats One row per statement in a batch Execution count, Plan generation count IO, Duration Plan_handle, Sql_handle Query_hash, Query_plan_hash Demo for both views Explain about both of them and only then show them in SSMS A plan is per batch Each statement is optimized by itself Explain about plan genration num

Diving In - Functions sys.dm_exec_sql_text sys.dm_exec_query_plan Pass plan_handle/sql_handle to get batch text Use offsets to get query level text sys.dm_exec_query_plan Use to get the query plan Returns XML plan of all the statements in a batch sys.dm_exec_text_query_plan Use to get the plan at the statement level Returns nvarchar(max). Cast it to XML Explain about the top 3, then demo, then attributes, then demo Tell the 64 levels story in text_query_plans Explain that we can use it with option(use plan) or with plan guide Plan attributes examples: First: From the application looking for Nancy and from SSMS, Second: schema issues with user= Test password= Test

Cache Lookup Objects (Stored Procedures, Functions, Triggers) (ObjectID * DB_ID) % (Hash Table Size) Ad-hoc and prepared statements ObjectID = Query Text Hash Exact text match is needed Also for reuse to be possible: Set Options User ID (Schema ID) DB_ID And More… Ad-hoc lookup demo

Common Problems: Ad-hoc Lots of plans with use count of 1 Not necessarily user queries ADO.Net, EXEC(), System Queries How to identify: Search for ad-hoc plans with use count = 1 “The word ad-hoc is misleading” Look for ad-hoc plans + Optimize for ad hoc workloads demos Prepared demo Forced parameterization demo – shall queries and only prepared is used For plan guide - http://msdn.microsoft.com/en-us/library/ms179880.aspx

Common Problems: Ad-hoc Optimization options: Optimize for ad hoc workloads Switch to parameterized methods Turn on Forced Parameterization Try to test it’s appropriate for your system Can also be used selectively through plan guides “The word ad-hoc is misleading” Look for ad-hoc plans + Optimize for ad hoc workloads demos Prepared demo Forced parameterization demo – shall queries and only prepared is used For plan guide - http://msdn.microsoft.com/en-us/library/ms179880.aspx

Recommended Query #1 SELECT SUM(CAST(size_in_bytes BIGINT))/1024.0/1024.0 AS SizeInMB, COUNT(*) AS PlanCount FROM sys.dm_exec_cached_plans WHERE objtype = 'Adhoc' AND cacheobjtype = 'Compiled Plan' AND usecounts = 1

Common Application Problems Nhibernate String parameter lengths are supplied according to each specific execution Solution: Nhibernate “prepare_sql” parameter Linq To SQL & Entity Framework Same as Nhibernate Solution: Upgrade to Dot Net 4.0 Parameterized queries lack of reuse demo at the start Ask how many has Nhibernate and how many has Entity Framework Ask if someone turned on optimize for ad-hoc / forced parameterization Show how the parameterized queries look in the application at the end

Common Application Problems Simple ADO.Net queries Act as Ad-hoc queries Optimization options: Optimize for ad-hoc workloads option ADO.Net parameterized queries (supply length for strings) Forced parameterization Parameterized queries lack of reuse demo at the start Ask how many has Nhibernate and how many has Entity Framework Ask if someone turned on optimize for ad-hoc / forced parameterization Show how the parameterized queries look in the application at the end

Query_hash & Query_plan_hash Can help identify potentially reusable queries Recommended query #2: SELECT query_hash,COUNT(*) AS PlanCount FROM sys.dm_exec_query_stats GROUP BY query_hash HAVING COUNT(*) > 1 Identify parameterization options and lack of reuse for sp’s. Explain the issue with optional_spid Same thing with query_plan_hash

Automatic Plan Eviction Age-out algorithm based on: Plan generation cost Usage On memory pressure, all plan costs are decreased by 1 Plans with cost = 0 can be evicted Ad-hoc plans always enter with cost = 0 Cost incremented by 1 on each reuse For other plans Cost is reset to the original value on reuse Ad-hoc max cost = 16 Prepared max cost = 256 No max cost for stored procedures sys.dm_os_memory_cache_entries

Manual Plan Eviction DBCC FREEPROCCACHE Can also be more specific Clears all plans Can also be more specific plan_handle / sql_handle / pool_name DBCC FREESYSTEMCACHE Specific cache store: ‘SQL Plans’ / ‘Object Plans’ Undocumented DBCC FLUSHPROCINDB – Specific database * Plan_handle – remove bad parameter sniffed plan like I had with Sergey * FreeSystemCache – I can decide I want to drop the whole cache that holds ad-hoc and prepared because developers don’t want to change their code

Searching For Problematic Queries We can answer questions like: Which queries are most IO/CPU/Time intensive? Absolute numbers or per run Which database is the most resource intensive? What is the value a plan was optimized for? Which queries/objects are frequently recompiled? And much more.. “Now, that we know how everything works, we can start searching for problematic queries” Populate Cache before demoes Demoes all the way down until Querying execution plan xml.

The Recompile Dilemma Plan is optimized for first execution’s parameters Local variable values not known to the optimizer Possible solution: Recompile Stored procedure level: Create Procedure..With Recompile Exec..With Recompile sp_recompile Statement level: Option (Recompile) As we saw, it comes with a performance penalty We can live with the performance penalty if the queries turn out to run faster “But there’s one problem with this issue”

But there’s a problem

Recompile Ruins the Statistics We Rely On When Querying the Plan Cache!

The Recompile Dilemma Create Procedure..With Recompile means: “Generate new plan on each run and don’t cache it” Exec..With Recompile means: “Generate new plan for this run and don’t cache it” Option (Rcompile) means: Generate new plan on each run Set execution_count to 1 Increase plan_generation_num by 1 We can find option(recompiles) by looking for plans with high plan generation num and execution count of 1 Option(recompile) won’t cache if it’s ad-hoc/prepared and it’s the only statement

Other Solutions Local variable problem? Parameter Sniffing problem? Pass the values as parameters from the outside Use Dynamic-SQL (preferably sp_executesql) Parameter Sniffing problem? Multiple procedures for different cardinalities Optimize for (@param = value) Optimize for unknown / parameter masking Plan freezing sp_create_plan_guide_from_handle Option (use plan) Can also be done with a plan guide

Querying Execution Plan XML Can answer questions like: Which plans suffer from missing indexes? Which plans suffer from Implicit_Conversion? Which plans use a Clustered Index Scan? Which plans have inaccurate row count estimation? And more.. Demoes all the way down

Summary Reuse is almost always a good thing Try to prevent Plan Cache bloat Remember the effects of Recompile The Plan Cache is your workload – Get to know it Scripts: madeirasql.com/things-you-can-find-sqlbits

Keep in touch Name: Matan Yungman Role: Professional Manager at Madeira Website: www.madeirdata.com Mail: matan@madeira.co.il Twitter: @MatanYungman Podcast: www.sqlserverradio.com

Thank you !