SQL Programmability & API Development Team Blog : SQL Server 2005

4.0 Useful Queries on DMV’s to understand Plan Cache Behavior

sangeethashekar — Tue, 23 Jan 2007 10:00:00 GMT

The following queries can be used to understand plan cache behavior. It should be noted that for systems with large plan caches, selecting all rows and joining with sys.dm_exec_sql_text is not recommended. To find the size of the plan cache use:

select (sum(single_pages_kb) + sum(multi_pages_kb) ) * 8 / (1024.0 * 1024.0) as plan_cache_in_GB

from sys.dm_os_memory_cache_counters

where type = 'CACHESTORE_SQLCP' or type = 'CACHESTORE_OBJCP'

To view the cached plans use the query sys.dm_exec_cached plans and sys.dm_exec_sql_text. The query below gives the sql text of the query, number of times the query has be executed (or reused), cacheobjtype (Compiled Plan/Extended Stored

Procedure/Parse Tree), objtype (View/Proc/Adhoc), bucketid in the hash table these plans are hashed to, and the plan handle.

select top 1000 st.text, cp.cacheobjtype, cp.objtype, cp.refcounts, cp.usecounts, cp.size_in_bytes, cp.bucketid, cp.plan_handle

from sys.dm_exec_cached_plans cp

cross apply sys.dm_exec_sql_text(cp.plan_handle) st

where cp.cacheobjtype = 'Compiled Plan'

and cp.objtype = 'Prepared'

order by cp.usecounts desc

select top 1000 st.text, cp.cacheobjtype, cp.objtype, cp.refcounts, cp.usecounts, cp.size_in_bytes, cp.bucketid, cp.plan_handle

from sys.dm_exec_cached_plans cp

cross apply sys.dm_exec_sql_text(cp.plan_handle) st

where cp.cacheobjtype = 'Compiled Plan'

and cp.objtype = 'Adhoc'

order by cp.usecounts desc

Parameterization of queries gives a significant performance benefit. Parameterized queries have objtype 'Prepared'. Prepared queries typically have large usecounts and are greater in size than the corresponding adhoc shell queries (less than 50K for adhoc shell queries). Plans for stored procedures also have a high degree of reuse. In some workloads, there is reuse of adhoc queries with the exact same parameter values. In such cases caching of the shell query proves gives better throughput.

Sorting the data on usecounts gives the information regarding the degree of reuse of queries. The query below sorts the cached plans on the plan size. This query can be used to identify large plans. Caching several un-parameterized adhoc queries with large plan size and with no reuse will lead to plan cache bloating. This causes the plan cache to be under constant memory pressure and gives suboptimal performance results. It is therefore important to try to parameterize queries.

select top 1000 st.text, cp.cacheobjtype, cp.objtype, cp.refcounts,

cp.usecounts, cp.size_in_bytes, cp.bucketid, cp.plan_handle

from sys.dm_exec_cached_plans cp

cross apply sys.dm_exec_sql_text(cp.plan_handle) st

where cp.cacheobjtype = 'Compiled Plan'

and (cp.objtype = 'Adhoc' or cp.objtype = 'Prepared')

order by cp.objtype desc, cp.size_in_bytes desc

The DMV sys.dm_os_memory_cache_entries has the number of 8KB pages allocated for the plan, the number of disk IO's associated with this entry, the number of context switches associated with this query, the original and current cost for the entry. Original cost of the entry is an approximation of the number of I/Os incurred, memory, and the context switch count. The current cost of the entry is the actual cost associated with the query. A query is inserted into the cache with a zero current cost. Its current cost is incremented by one on every re-use. The maximum value of the current cost is the original cost of query. Entries with zero current cost will be removed when the plan cache is under memory pressure. Use either query below to get this information:

Select top 1000 st.text, cp.objtype, cp.refcounts, cp.usecounts, cp.size_in_bytes,

ce.disk_ios_count, ce.context_switches_count,

ce.pages_allocated_count, ce.original_cost, ce.current_cost

from sys.dm_exec_cached_plans cp

cross apply sys.dm_exec_sql_text(cp.plan_handle) st

join sys.dm_os_memory_cache_entries ce

on cp.memory_object_address = ce.memory_object_address

where cp.cacheobjtype = 'Compiled Plan'

and (cp.objtype = 'Adhoc' or cp.objtype = 'Prepared')

order by cp.objtype desc, cp.usecounts desc

select st.text, cp.objtype, cp.refcounts, cp.usecounts, cp.size_in_bytes,

ce.disk_ios_count, ce.context_switches_count,

ce.pages_allocated_count, ce.original_cost, ce.current_cost

from sys.dm_exec_cached_plans cp

cross apply sys.dm_exec_sql_text(cp.plan_handle) st

join sys.dm_os_memory_cache_entries ce

on cp.memory_object_address = ce.memory_object_address

where cp.cacheobjtype = 'Compiled Plan'

and ce.type in ('CACHESTORE_SQLCP', 'CACHESTORE_OBJCP')

order by cp.objtype desc, cp.usecounts desc

To estimate the amount of plan cache memory that is being reused use:

select sum(size_in_bytes)/1000 as total_size_in_KB,

count(size_in_bytes) as number_of_plans,

((sum(size_in_bytes)/1000) / (count(size_in_bytes))) as avg_size_in_KB,

cacheobjtype, usecounts

from sys.dm_exec_cached_plans

group by usecounts, cacheobjtype

order by usecounts asc

The total_size_in_KB with usecounts > 1 represents the plan cache memory that is being reused.

To estimate the amount of memory that can be reclaimed after the next round of memory pressure use:

select ce.type, ce.current_cost,

sum(cp.size_in_bytes) as total_size_in_bytes

from sys.dm_exec_cached_plans cp

join sys.dm_os_memory_cache_entries ce

on cp.memory_object_address=ce.memory_object_address

where ce.type in ('CACHESTORE_SQLCP', 'CACHESTORE_OBJCP') and

ce.current_cost = 0

group by ce.type, ce.current_cost

The total_size_in_bytes with current_cost = 0 is the memory that will available after the next round of memory pressure.

The DMV sys.dm_os_memory_cache_clock_hands has information regarding how many clock rounds have been made for each cache store. The query below should return 4 rows, two for each cachestore. Each cachestore has an external and internal clock hand that distinguishes external and internal memory pressure respectively. The column removed_last_round_count indicates the number of entries (plans) removed in the last round, and the removed_all_rounds_count indicates the total number of entries removed.

select * from sys.dm_os_memory_cache_clock_hands

where type = 'CACHESTORE_SQLCP' or type = 'CACHESTORE_OBJCP'

The DMV sys.dm_os_memory_cache_counters has information on the single and multi-page allocations made for the SQLCP and OBJCP cachestores. A large number of multi_pages_kb can lead to a performance slowdown without SQL Server 2005 SP2.

select *, name, type, single_pages_kb, multi_pages_kb,

single_pages_in_use_kb, multi_pages_in_use_kb

from sys.dm_os_memory_cache_counters

where type = 'CACHESTORE_SQLCP' or type = 'CACHESTORE_OBJCP'

Alternatively, query sys.dm_os_memory_clerks to get the memory allocation information along with the memory_node_id:

select type, name, memory_node_id, single_pages_kb, multi_pages_kb

from sys.dm_os_memory_clerks

where type = 'CACHESTORE_SQLCP' or type = 'CACHESTORE_OBJCP'

The DMV sys.dm_os_memory_cache_hash_tables has information on the hash bucket length for SQLCP and OBJCP cachestores. A large value for buckets_average_length and a small value for buckets_in_use_count indicate long chains in each hash bucket. Long hash bucket lengths can lead to performance slowdown.

select name, type, buckets_count, buckets_in_use_count,

buckets_min_length, buckets_max_length, buckets_avg_length

from sys.dm_os_memory_cache_hash_tables

where type = 'CACHESTORE_SQLCP' or type = 'CACHESTORE_OBJCP'

Note that by removing the where clause in queries 5 though 7 we can get information for

other cachestores also.

If the size of the plan cache is over a few GB use the following queries:

To get a count of the number of compiled plans use:

select count(*) from sys.dm_Exec_Cached_plans

where cacheobjtype = 'Compiled Plan'

To get a count of the number of adhoc query plans use:

select count(*) from sys.dm_Exec_Cached_plans

where cacheobjtype = 'Compiled Plan'

and objtype = 'Adhoc'

To get a count of the number of prepared query plans use:

select count(*) from sys.dm_Exec_Cached_plans

where cacheobjtype = 'Compiled Plan'

and objtype = 'Prepared'

For the number of prepared query plans with a given usecount use:

select usecounts, count(*) as no_of_plans

from sys.dm_Exec_Cached_plans

where cacheobjtype = 'Compiled Plan'

and objtype = 'Prepared'

group by usecounts

For the number of adhoc query plans with a given usecount use:

select usecounts, count(*) as no_of_plans

from sys.dm_Exec_Cached_plans

where cacheobjtype = 'Compiled Plan'

and objtype = 'Adhoc'

group by usecounts

For the top 1000 adhoc compiled plans with usecount of 1 use:

select top(1000) * from sys.dm_Exec_cached_plans

cross apply sys.dm_exec_sql_text(plan_handle)

where cacheobjtype = 'Compiled Plan'

and objtype = 'Adhoc' and usecounts = 1

To take a full dump turn on T2544 and T8004 (trigger a dump when the lazy writer cannot provide enough free buffers) and execute: dbcc stackdump(0)

3.0 Changes in Caching Behavior between SQL Server 2000, SQL Server 2005 RTM and SQL Server 2005 SP2

sangeethashekar — Mon, 22 Jan 2007 10:00:00 GMT

3.1 Costing algorithm change between SQL Server 2000 and SQL Server 2005 RTM

In SQL Server 2000 and 2005, the cost of a query depends on 3 factors: number of disk IO requests, number of context switches during query compilation (in 4 ms quantums) and the number of memory pages, both from single and multi-page allocations. In SQL Server 2005, the original cost of the query is a power of two, the exponent being the sum of the contributions of disk IO’s, context switches and memory pages to the cost.

Mathematically

Cost = 2 ^{min (IO > 0 ? (IO - 1) / 2 + 1 : 0, 19) + min (CS > 1 ? (CS - 1) / 2 + 1 : 0, 8) + min (MP / 16, 4)}

Where

IO - the number of IO requests (regardless of the number of bytes involved),

CS - the number of context switches, i.e. the number of 4 ms quantums,

MP - the number of memory pages (from both single and multi page allocations)

The contribution of context switches is as follows: a) for queries with zero or one context switches, the contribution is zero. For queries with number of context switches two, the contribution is one. For every two context switches over two, the contribution increases by one up to a maximum of eight. The disk IO’s contribution is zero if the number of disk IO’s is zero. For every two disk IO’s over zero, the contribution increases by one up to a maximum of nineteen. The contribution from memory pages is the number of pages divided by sixteen up to a maximum of four. To illustrate with an example: if a query has zero disk IO’s, four context switches, and 2 memory pages, then original cost is 2^{(0 + 2 + 0)} = 4

SQL Server 2005 the cost computed is directly proportional to the memory pages for the plan, where as in SQL Server 2000 the cost computed is inversely proportional to the memory pages. Therefore queries that take up a large number of memory pages are not cached in SQL Server 2000, but will be cached in SQL Server 2005. On an upgrade, for a workload with large queries and limited reuse this will result in dramatic increase in plan cache size.

3.2 Improvements made to Plan Cache behavior in SQL Server 2005 SP2

Reduce contention in the creation and eviction of plan cache entries: In SQL Server 2005 RTM and SP1, there is a single allocator for all descriptors of compiled plans of dynamic queries. The descriptor is the part of the compiled plan that must be created to add the compiled plan to the plan cache and it must be destroyed to evict the compiled plan from the plan cache. The contention on this single allocator can cause as much as a 40% drop in application throughput or, in more severe cases, an Out of Memory error. In SP2, we partition the allocator per CPU to reduce this contention, thus increasing throughput and eliminating the Out of Memory error.

Implemented fairness policy in evicting cache entries across all NUMA nodes: For servers with non-uniform memory access (NUMA) configuration (Hardware-NUMA or Soft-NUMA), there will be multiple NUMA nodes and different caches will be placed on different NUMA nodes. SQL Server responds to memory pressure by evicting cache entries. In SQL Server 2005 RTM and SP1, this can cause small caches on one NUMA node (such as the metadata cache) to go through multiple rounds of eviction while large caches (plan cache for instance) on a different NUMA node have yet to finish one round. As an example, entries in the small metadata cache have to be constantly recreated thus causing contention on the schema modification lock. This contention leads to significant drop in throughput. In SP2, we implemented a fairness policy in evicting cache entries across all NUMA nodes, thus avoiding the drop in throughput.

Align SQL Server 2005 plan cache size limit to a size similar to that of SQL Server 2000: The maximum size limit of the SQL Server 2005 Plan Cache in RTM and SP1 is significantly larger than in SQL Server 2000. To reduce the SQL Server 2005 plan cache maximum size limit to a size similar to that of SQL Server 2000, the limit for signaling internal memory pressure on a cache is changed from that of SQL Server 2005 RTM and SP1. The following table shows how the maximum limit of the plan cache is determined for each version of SQL Server:

SQL Server Version	Internal Memory Pressure Indication in Cachestore
SQL Server 2005 RTM & SP1	75% of server memory from 0-8GB + 50% of server memory from 8Gb-64GB + 25% of server memory > 64GB
SQL Server 2005 SP2	75% of server memory from 0-4GB + 10% of server memory from 4Gb-64GB + 5% of server memory > 64GB
SQL Server 2000	SQL Server 2000 4GB upper cap on the plan cache

Example:

For a SQL Server with 32Gb total SQL server memory, SQL Server 2005 RTM and SP1 cachestore limit will be 75% X 8 + 50% X (32 - 8) = 18GB

SQL Server 2005 SP2 cachestore limit will be 75% X 4 + 10% X (32-4) = 5.8GB

Limiting the maximum size of the plan cache will ensure enough room for the database pages, and therefore improved throughput.

Note: Another internal memory pressure indication in the plan cache cachestore is 40K or more entries in the cachestore for 32 bit machine and 160K entries for 64 bit machine.

Decrease the number of plan cache entries by not caching some zero cost plans: In SQL Server 2005 RTM, SP1 and SP2, the cost of a compiled plan is directly proportional to the size of the compiled plan, the IO and CPU cost to compile the plan. A compiled plan is considered zero cost if the cost is below a certain threshold. In SQL Server 2005 RTM and SP1, zero cost compiled plans for dynamic batches containing at least one set (option) statement and/or at least one transaction statement (begin/commit/save/rollback transaction statement) are cached. In SP2, these plans are no longer cached. The only exceptions are:

a. For the set (option) statement, if all the statements in the batch are set (option) statements, SP2 will still cache the batch even if it is zero cost.

b. For transaction statements (begin/commit/save/rollback transaction statements), if all the statements in the batch are IF statements and/or transaction statements (begin/commit/save/rollback transaction statements), SP2 will still cache the batch even if it is zero cost.

This change in SP2 reduces caching zero cost plans for dynamic batches that are almost never reused due to the randomness of parameters while allowing reuse of batches that are likely to be same.

2.0 Diagnosing Plan Cache Related Performance Problems and Suggested Solutions

sangeethashekar — Sun, 21 Jan 2007 10:00:00 GMT

Plan cache related performance problems usually manifest in decrease in throughput (or increase in query response time), and some times out of memory errors, connection time outs. None of these symptoms however point to plan cache related performance problems specifically. In order to determine and further isolate the cause of the slowdown the following steps are recommended:

2.1 Periodically query sys.dm_os_wait_stats and examine the waits

CMEMTHREAD waits: This wait type indicates that the rate of insertion of entries into the plan cache is very high and there is contention on the memory object from which the cache descriptors are allocated from. Contention is also observed when entries are being removed from the plan cache resulting in the resource monitor thread being blocked. There is a single memory object per cachestore from which the cache descriptors for the cachestore are allocated. Since there is a single global cachestore for the ad-hoc compiled plans, there is only one thread safe memory object creating the cache descriptors for each cacheable compiled plan.

For example: Consider the following query batch:

begin tran;

exec sp_some_procedure 'param1';

exec sp_some_procedure 'param2';

exec sp_some_procedure 'param3';

exec sp_some_procedure 'param4';

exec sp_some_procedure 'param5';

exec sp_some_procedure 'param6';

exec sp_some_procedure 'param7';

exec sp_some_procedure 'param8';

exec sp_some_procedure 'param9';

exec sp_some_procedure 'param10';

commit tran;

Each time the batch is executed with different parameter values passed to the stored procedure making the batch unique. This batch is cached in SQL Server 2005 and not in SQL Server 2000 due to different costing formulas and heuristics. Hence on upgrade from SQL Server 2000 this manifests as a significant drop in throughput once memory pressure is reached in SQL Server 2005 SP1 and sometimes OOM (out of memory) errors as well if resource monitor is not able to keep up with cache insertions. Query sys.dm_os_wait_stats looking for wait of type CMEMTHREAD:

select * from sys.dm_os_wait_stats

order by waiting_tasks_count desc

On a 32 processor, 8 Node NUMA Machine when this batch is executed over 64 connections there are a large number of CMEMTHREAD waits seen in sys.dm_os_wait_stats. SQL Server 2005 SP2 has a 2 part fix for the query batch described above: a) Zero cost queries that have set statements and transaction statements are no longer cached, unless the batch is entirely composed of set and/or transaction statements. This should dramatically reduce the rate of insertion of plans into the cache. b) Partition the memory object from which the cache descriptors are allocated per CPU. This will reduce the contention around the memory object, and therefore CMEMTHREAD waits.

Another approach to reducing contention would be examine the application code and use batched RPC to execute stored procedures.

SOS_RESERVEDMEMBLOCKLIST waits:

select * from sys.dm_os_wait_stats

order by wait_type

A large number of waits of type SOS_RESERVEDMEMBLOCKLIST indicates that the query probably has a procedure with a large number of parameters, or the query has a long list of expression values specified in an IN clause, which would require multi-page allocations. When such queries are executed concurrently over multiple connections on 64 bit systems, there is a severe degradation in throughput especially when the total multi-page allocations exceed a couple of GB.

Consider the example below where the select query has an IN clause with a large number of values specified in the expression list:

select col3 from t1 where col1 = 5 and col2 in (

'1', '2', '3', '4', '5', '6', '7', '8', '9', '10',

'500')

When this query is executed with different values of literals in the IN clause over multiple connections, the multi-page allocations are made. Another example of when multi-page allocations are made is execution of a stored procedure that takes a large number of parameters over multiple connections, each time with different parameter values:

exec p1 '1', '2', '3', '4', ...'500'

Sys.dm_os_memory_cache_counters has the multipages allocated in KB (multi_pages_kb):

select name, type, single_pages_kb, multi_pages_kb,

single_pages_in_use_kb, multi_pages_in_use_kb

from sys.dm_os_memory_cache_counters

where type = 'CACHESTORE_SQLCP' or type = 'CACHESTORE_OBJCP'

It is also worth noting that periodically executing 'dbcc freeproccache' alleviates the problem temporarily. SQL Hotfix 543 contains the multi-page allocator fix to reduce this contention. SQL Server 2005 SP2 includes this Hotfix and has an additional fix to relieve contention on this wait type. Note that the fix in SP2 is not guaranteed to fix the contention on this wait type, but should reduce the contention. It is also worth examining the client application for alternatives to passing long parameter list to functions or stored procedures or rewriting queries with a long IN clause.

RESOURCE_SEMAPHORE_QUERY_COMPILE waits:

select * from sys.dm_os_wait_stats

order by wait_type

A large number of waits of type RESOURCE_SEMAPHORE_QUERY_COMPILE indicates a large number of concurrent compiles. In SQL Server 2005 we limit the number of compiles than can start at any given time to prevent the following scenario: a large number of compilations are initiated and memory partially allocated. A large percentage of queries land up being suspended (waiting) for resources to complete compilation, eventually timing out and releasing memory allocated to them. This is an inefficient use of server resources, and hence in SQL Server 2005 there is a limit on the number of concurrent compiles that use a lot of memory at any given time. In such scenarios examine the entries in the plan cache to see if queries are getting compiled as follows:

select usecounts, cacheobjtype, objtype, bucketid, text

from sys.dm_exec_cached_plans cp cross apply

sys.dm_exec_sql_text(cp.plan_handle)

where cacheobjtype = 'Compiled Plan'

order by objtype

If there are no rows returned from the above query with objtype 'Prepared' then queries are not getting parameterized. First thing to try here is to alter the database parameterization setting:

alter database <database_name> set parameterization forced

However the recommended approach is to use plan guides for queries and specify parameterization option as forced instead of changing the database parameterization option. For example:

When the database parameterization option is set to simple the following query does not get parameterized:

select t1.col1 from t1 join t2 on t1.col1 = t2.col2 join t3 on t2.col1 = t3.col1 where t1.col1 = 200

When executed concurrently with different parameter values on a multi-processor machine results in large number of waits of type RESOURCE_SEMAPHORE_QUERY_COMPILE. When the database parameterization option is set to forced, the query gets parameterized as:

(@0 int)select t1.col1 from t1 join t2 on t1.col1 = t2.col2 join t3 on t2.col1 = t3.col1 where t1.col1 = @0

A more suitable alternative to setting the database parameterization option to forced would be to use plan guides as below:

declare @stmt nvarchar(max), @params nvarchar(max);

exec sp_get_query_template

N'select t1.col1 from t1 join t2 on t1.col1 = t2.col2 join t3 on t2.col1 = t3.col1 where t1.col1 = 200',

@stmt output, @params output;

exec sp_create_plan_guide N'TemplateGuide',

@stmt, N'template', NULL,

@params, N'option(parameterization forced)';

For more information see 'Designing Plan Guides for Parameterized Queries'.

It is important to note that when specifying query parameters all statements in the batch should be parameterized. Consider the example below:

declare @intvalue int, @sqlstring nvarchar(500),

@parmdefinition nvarchar(500), @col2 int;

set @intvalue = 5;

set @sqlstring = N'select @col2_out = col2 from t1 where col1 = @param; update t1 set col1 = col1 + 1 where col2 = 6';

set @parmdefinition = N'@param int, @col2_out int output';

exec sp_executesql @sqlstring, @parmdefinition, @param = @intvalue, @col2_out = @col2 output;

set @sqlstring = N'select @col2_out = col2 from t1 where col1 = @param; update t1 set col1 = col1 + 1 where col2 = 7';

exec sp_executesql @sqlstring, @parmdefinition, @param = @intvalue, @col2_out = @col2 output;

The select statement has been parameterized, while the update statement has not been parameterized making each batch unique. When these 2 batches are executed, there is a compiled plan for each batch in the cache.

(@param int, @col2_out int output)select @col2_out = col2 from t1 where col1 = @param; update t1 set col1 = col1 + 1 where col2 = 7

(@param int, @col2_out int output)select @col2_out = col2 from t1 where col1 = @param; update t1 set col1 = col1 + 1 where col2 = 6

With no reuse of the prepared compiled plan, every batch that comes in is compiled and a fresh plan is inserted into the cache. This will lead to performance degradation due to large number of compiles and plan cache bloating. Therefore it is important to make sure all statements in the batch are parameterized as follows:

declare @intvalue int, @sqlstring nvarchar(500),

@parmdefinition nvarchar(500), @col2 int;

set @sqlstring = N'select @col2_out = col2 from t1 where col1 = @param1; update t1 set col1 = col1 + 1 where col2 = @param2';

set @parmdefinition = N'@param1 int, @param2 int, @col2_out int output';

set @intvalue = 5;

exec sp_executesql @sqlstring, @parmdefinition, @param1 = @intvalue, @param2 = @intvalue, @col2_out = @col2 output;

set @intvalue = 6;

exec sp_executesql @sqlstring, @parmdefinition, @param1 = @intvalue, @param2 = @intvalue, @col2_out = @col2 output;

The compiled plan generated for both batches is:

(@param1 int, @param2 int, @col2_out int output)select @col2_out = col2 from t1 where col1 = @param1; update t1 set col1 = col1 + 1 where col2 = @param2

2.2 Periodically look at the spins and collisions data

create table t_spinlock_stats

(spinlockname varchar(64), collisions int,

spins int, [spins/collisions] int)

insert into t_spinlock_stats

exec ('dbcc sqlperf(spinlockstats)');

select * from t_spinlock_stats order by collisions desc

1. If the numbers of collisions (and spins) for SQL_MGR is relatively high, next examine the parameterized queries:

select usecounts, cacheobjtype, objtype, bucketid, text

from sys.dm_exec_cached_plans cp cross apply sys.dm_exec_sql_text(cp.plan_handle)

where cacheobjtype = 'Compiled Plan' and objtype = 'Prepared'

order by bucketid

If there are a large number of parameterized queries with the exact same sql text but different parameter lists, and identical bucketid’s then this might explain the large number of collisions for SQL_MGR.

For example:

select * from foo where col2 = 2.23

translates to: (@1 numeric(3,2))SELECT * FROM [foo] WHERE [col2]=@1

select * from foo where col2 = 2.2

translates to:(@1 numeric(2,1))SELECT * FROM [foo] WHERE [col2]=@1

When a statement is parameterized by the server (either simple or universal parameterization) it makes type decisions based on the parsed type. If the parameter passed is numeric, then the type is determined based on precision and scale. So a value like 2.2 will have a type of numeric(2, 1) and 2.23 will have a type of numeric(3, 2). For varchar data type, server side parameterization will not exhibit this behavior. For example:

select * from table1 where col1 = 'abc'

select * from table1 where col1 = 'abcd'

both translate to:

(@0 varchar(8000))select * from table1 where col1 = @0

Failing to set the max length of the parameter when using client side parameterization, can however generate one parameterized plan for each parameter value with a different length. For example:

using SqlConnection myConnection = new SqlConnection ("context connection = true");

SqlCommand myCommand = new SqlCommand("SELECT * FROM t1 WHERE col1 = @ID", myConnection );

myCommand.Parameters.Add( "@ID", SqlDbType.VarChar);

myCommand.Parameters["@ID"].Direction = ParameterDirection.Input;

myCommand.Parameters["@ID"].Value = "ABC";

myConnection.Open();

myCommand.ExecuteNonQuery();

myCommand.Parameters["@ID"].Value = "ABCD";

myCommand.ExecuteNonQuery();

myConnection.Close();

This translates to two parameterized queries i.e. unique parameterized query if the length of the parameter is different.

(@ID varchar(3))SELECT * FROM t1 WHERE col1 = @ID

(@ID varchar(4))SELECT * FROM t1 WHERE col1 = @ID

If you pass different literal values with different number of decimal points they will all have the same parameterized query text but the types in the parameter list is different. The Sql 2005 caching algorithm uses only the parameterized query text to compute the hash value for the entry, and so it is possible to have a very large number of entries with the same query text but different parameter lists. This leads to long lookup times for the cache entries and high CPU as it walks the hash chain and does comparisons on many similar entries.

SQL Hotfix 716 (fix also in SQL Server 2005 SP2) fixes this issue by computing the hash value based on the entire query text including the parameter list. Minor modifications to the application code can mitigate the problem when the parameter type is varchar. It is recommended that the max length is always set suitably when using ADO.NET as illustrated below in the code snippet:

using SqlConnection myConnection = new SqlConnection ("context connection = true");

SqlCommand myCommand = new SqlCommand("SELECT * FROM t1 WHERE col1 = @ID", myConnection );

myCommand.Parameters.Add( "@ID", SqlDbType.VarChar, 20);

myCommand.Parameters["@ID"].Direction = ParameterDirection.Input;

myCommand.Parameters["@ID"].Value = "ABC";

myConnection.Open();

myCommand.ExecuteNonQuery();

myCommand.Parameters["@ID"].Value = "ABCD";

myCommand.ExecuteNonQuery();

myConnection.Close();

This translates into one parameterized query irrespective of the length of the actual parameter passed in:

(@ID varchar(20))SELECT * FROM t1 WHERE col1 = @ID

2. If the numbers of collisions (and spins) for SPL_MUTEX is high, then examine your application code to see if queries are being executed under a security context other than the sysadmin.

Examine the size (single_pages_kb) of the TokenAndPermUserStore cache either through dbcc memorystatus or through the sys.dm_os_memory_clerks DMV. The number of single_pages_kb should be very high.

select type, name, single_pages_kb,

multi_pages_kb, memory_clerk_address

from sys.dm_os_memory_clerks where type =

'USERSTORE_TOKENPERM'

Next examine the buckets_count in sys.dm_os_memory_cache_hash_tables and look for long hash bucket chains:

select type, name, cache_address, buckets_count, buckets_in_use_count,

from sys.dm_os_memory_cache_hash_tables

where type = 'USERSTORE_TOKENPERM'

Symptoms above describe a situation where performance degrades because access to many entries in the TokenAndPermUserStore cache is going through a single spinlock. This is because entries end up in the same hash bucket. This leads to the response time of queries degrading significantly and has been observed on 64 bit systems.

If yes, next try to free the token and permissions cache (TokenAndPermUserStore) and see if that temporarily alleviates the problem:

dbcc freesystemcache ('TokenAndPermUserStore')

Changes to the application code that avoid this problem include executing all queries under the context of sysadmin to bypass security checks. A server side fix for this issue will be shipped as part of SP2.

2.3 Monitor Plan Cache size and Database pages size

Collect 'SQL Server: Plan Cache\Cache Pages(_Total)' and 'SQLServer: BufferManager\Database pages' performance counters. Typically the database pages increases along with the plan cache pages especially for workloads with adhoc queries. However due to the difference between SQL Server 2000 and SQL Server 2005 plan cache size limits, it is possible for the plan cache pages to grow up to ~80% of buffer pool without being under memory pressure leaving no room for database pages. This results in the database pages being evicted and subsequent performance degradation. The max limit of SQL Server 2005 Plan Cache size in SQL Server 2005 RTM and SP1 is bigger than in SQL Server 2000. To bring the SQL Server 2005 plan cache size limit to be similar to that of SQL Server 2000, in SP2 the limit for signaling internal memory pressure on a cachestore will be changed as described in section 4.

Trouble Shooting Query Performance Issues Related to Plan Cache in SQL 2005 RTM and SP1

sangeethashekar — Sat, 20 Jan 2007 10:00:00 GMT

If after upgrading from SQL 2000 to SQL 2005 RTM and/or SP1, you notice decreased OLTP database application throughput, bloated plan cache or out of memory errors, you will need to gather machine configuration information and system performance data in order to perform a detailed analysis. Below, we will outline the steps to take to gather relevant data in order to determine if the problem is plan cache related.

1.0 Machine Configuration Information That Can Impact Plan Cache Size/Performance

Machine configuration and server settings can impact plan cache performance. This section covers a check list of these settings/options that need to be examined as a first step to diagnosing a performance regression.

1.1 Understanding the Machine Configuration:

Processor:

(i) Processor Architecture: Recommendations for server settings for optimal plan cache behavior varies with the platform (x86/IA64/x64). The machine platform can be found executing 'set PROCESSOR_ARCHITECTURE' at the command prompt. Also check the platform of SQL Server to see if we are running under WOW. Note that on 64 bit this depends on whether you are running %systemroot%\system32\cmd.exe or %systemroot%\SysWOW64\cmd.exe. It will show x86 for the WOW version of the command console.

(ii) Total number of processors: The DMV sys.dm_os_sys_info has this information:

select cpu_count from sys.dm_os_sys_info

(iii) NUMA Architecture and Number of Nodes: The number of memory nodes on a machine can be found using:

select distinct top 1 instance_name + 1 as number_of_nodes

from sys.dm_os_performance_counters

where object_name = 'SQLServer:Buffer Node'

Also check the errorlog for the entries as below for the number of CPU nodes:

TimeStamp Server Multinode configuration: node 0: CPU mask: 0x00000000000000f0 Active CPU mask: 0x00000000000000f0. This message provides a description of the NUMA configuration for this computer. This is an informational message only. No user action is required.

This should give the number of CPU nodes as well as the CPU Mask set.

(iv) If NUMA Architecture, Number of processors per Node: If Soft NUMA configurations have not been used then the following query gives a mapping of CPU to nodes:

select parent_node_id, scheduler_id from sys.dm_os_schedulers

where scheduler_id < 255

order by scheduler_id desc

If soft NUMA has been used, the number of CPU nodes is greater than the number of hardware NUMA nodes. The above query then maps the CPUs to CPU nodes, not hardware NUMA nodes. To check if the machine has been configured with soft NUMA search the registry for keys under:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\90\NodeConfiguration\. If there are keys present here they define the soft NUMA mapping of processors to soft NUMA nodes. For more information see BOL article ‘How to: Configure SQL Server to Use Soft-NUMA’.

Memory:

(i) Total Physical Memory:

select physical_memory_in_bytes/(1024.0*1024.0*1024.0) as physical_mem_in_gb

from sys.dm_os_sys_info

(ii) If NUMA Architecture, Memory allocated per Node (in 8K pages):

select cntr_value

from sys.dm_os_performance_counters

where object_name = 'SQLServer:Buffer Node' and counter_name = 'Total pages'

The plan cache is logically on node 0 on a multi node machine. This however does not imply that all the memory for the plan cache comes from node 0 only. To better explain this, consider the following example: A multi-node machine has 2 NUMA nodes, the buffer pool has 2 memory nodes, nodes 0 and 1 respectively. Schedulers s1, s2, s3 are associated with NUMA node 0 and s4, s5, s6 with NUMA node 1. The plan cache/memory clerk is on memory node 0. When scheduler s4 requests 2 pages for a new PMO (plan), the buffer pool tries to allocate the pages locally through the NUMA node these schedulers are associated with i.e. through node 1. Even though these pages were allocated from NUMA node 1, the cachestore memory clerk which is logically on node 0, will show a total of 2 pages. Therefore allocating more memory to NUMA node 0 just because the plan cache is on node 0 will not help performance. It may actually land up negatively impacting performance due to large number of remote memory accesses if queries are affinitized uniformly among nodes. If the memory allocated per node is not uniform in general it is better to affinitize the workload to nodes that have sufficient memory. Ideally queries should be affinitized to nodes through specific ports (if possible). If SQL Server has been configured to run on a subset of the available NUMA nodes, the buffer pool will not automatically be limited to the memory on those nodes. In this case, use the max server memory option to limit the buffer pool.

(iii) Lock Pages In Memory Privilege: This is an operating system privilege that allows locking of physical memory preventing OS paging of the locked memory. This privilege needs to be granted to the service account of sql server. On 32 bit architecture systems with sql server standard, enterprise and developer editions, this privilege needs to be granted to the sql server service account in order to use the AWE mechanism. On 64 bit architecture systems with any sql server edition, granting this privilege to the sql server service account is recommended. Note that a system restart is required after granting this privilege local system accounts for the permission to take effect. For domain users a fresh login is required. A quick and easy way to check (though non conclusive) if this privilege has been granted correctly on 32 bit would be to try to turn on AWE enabled as follows:

sp_configure 'show advanced options', 1

reconfigure with override

sp_configure 'awe enabled', 1

reconfigure with override

If lock pages in memory privilege has not been granted to the service account, sp_configure will fail with the following error message:

Msg 5845, Level 16, State 1, Line 1

Address Windowing Extensions (AWE) requires the 'lock pages in memory' privilege which is not currently present in the access token of the process.

On 64 bit machines, execute 'dbcc memorystatus'. If the AWE Allocated memory is 0 then lock pages in memory privilege has not been granted to the service account or it has not taken effect. On 32 bit machines, if AWE Allocated is 0 in the data from dbcc memory status and the sp_configure option 'awe enabled' is set to 1, then lock pages in memory privilege has not been granted to the service account or it has not taken effect.

For more information on how to grant this privilege the sql server service account please refer to the MSDN article ‘How to: Enable the Lock Pages in Memory Option (Windows)’. Restarting the machine typically helps permissions granted to the sql server service account take effect.

(iv) /3GB Boot Parameter: This is an operating system boot parameter that enlarges the user-mode virtual address space to 3 GB on a 32 bit system with less than 16GB total physical memory. On a 32 bit system with greater than 16GB total physical memory adding this parameter limits the physical memory to 16GB. A 32 bit process running under WOW64 will have 4GB of user mode virtual address space.

(v) /UserVA Boot Parameter: Another switch with similar function as the /3GB switch is /UserVA=X where X is number in MB.

The following query will tell you if either the /3GB or the /UserVA boot parameter has been enabled:

select

case

when virtual_memory_in_bytes / 1024 / (2048*1024)

< 1 then 'No switch'

else '/3GB'

end

from sys.dm_os_sys_info

1.2 SQL Server Configuration Options

Max Worker Threads: The number of workers can be found using the sp_configure option:

sp_configure 'show advanced options', 1

reconfigure with override

sp_configure 'max worker threads'

Each worker has a stack associated with it. The stack size can be found:

select stack_size_in_bytes/(1024.0 * 1024.0) as stack_size_in_MB from sys.dm_os_sys_info

The memory allocated for worker stacks needs to be factored out of the total physical memory before considering what the sql server max server memory is set. A large number of worker threads can actually reduce the memory available for plan cache growth.

Max and Min Server Memory: Max server memory can be set less than or equal to total physical memory minus 2 or 3 GB for the OS/kernel processes minus stack space required for workers. Memory is used for cache pages as well as database pages. Setting max server memory fairly low can have a negative impact on performance since it will mean frequent flushing of database pages to disk under memory pressure. If SQL Server has been configured to run on a subset of the available NUMA nodes, the buffer pool will not automatically be limited to the memory on those nodes. In this case, use the max server memory option to limit the buffer pool. Typically min server memory is set less than or equal to max server memory. In the case of a dedicated server max server memory can be set equal to min server memory. Note that memory is allocated on demand only. Once allocated though, it will not shrink beyond min server memory.

Awe Enabled: The awe enabled can be found using the sp_configure option:

sp_configure 'show advanced options', 1

reconfigure with override

sp_configure 'awe enabled'

On 32 bit systems it is recommended to set AWE Enabled to 1. This allows sql server to go beyond the process virtual address space limit on 32 bit platforms. It will also allow buffer pool to shrink virtual address space (VAS) usage under VAS pressure that may occur due to lots of multi page allocations or CLR. On 64 bit systems, this setting has no effect.

CPU Affinity Mask:

It is recommended that the CPU affinity mask be set such that all processors are used uniformly. Note though that by setting this hard affinity, threads cannot move around. In the case of a NUMA machine, if one node has less memory than other nodes, then it is better to affinitize to other nodes (CPU's). The affinity mask can be found using the sp_configure option:

sp_configure 'show advanced options', 1

reconfigure with override

sp_configure 'affinity mask'

Startup Parameter -g: A command line start up parameter that can be used as follows:

sqlservr [-g memory_to_reserve]

Using this start up parameter, an integer number of megabytes (MB) of memory can be specified that SQL Server will leave available for memory allocations within the SQL Server process, but outside the SQL Server buffer pool. The memory outside of the memory pool is the area used by SQL Server for multipage allocations among other things like loading DLLs. The default is 256 MB on 32 bit systems and is reserved even if this start up option is not specified. Using a value lower than the default increases the amount of memory available to the buffer pool and thread stacks; this may, in turn, provide some performance benefit to memory-intensive workloads in systems that do not use many extended stored procedures, distributed queries, or automation objects or any SQLCLR. For applications that use SQLCLR heavily, limiting this memory may result in memory starvation. For such applications it is the memory_to_reserve is set beyond the default of 256 MB if a lot of memory is allocated in CLR. Specifying a higher than default value may prove beneficial to workloads that have many multipage allocations. Setting this start up parameter appropriately and tuning it based on the nature of the workload running on the server is recommended for optimal results.

For more information refer to the books online article at ‘Using the SQL Server Service Startup Options’

CLR Enabled: Enabling CLR causes the buffer pool to shrink in some cases, in turn reducing the memory available for plan cache growth. Memory for loading assemblies, and for the garbage collector heap and JIT heap comes from outside the buffer pool. If the size of this memory allocated is high, then it can cause virtual memory pressure causing the buffer pool to shrink. On WOW64 we block the upper 1 GB from CLR if enabled (and everybody else) leaving 3 GB for the virtual address space. CLR can be enabled using the sp_configure option:

sp_configure 'show advanced options', 1

reconfigure with override

sp_configure 'clr enabled'

Max Degree of Parallelism: A high setting for max degree of parallelism can reduce the amount of memory available for plan cache growth. This is because when the query runs a significant portion of the memory from the buffer pool is consumed for query execution leaving less room for the plan cache to grow. Max Degree of Parallelism set can be queried as follows:

sp_configure 'show advanced options', 1

reconfigure with override

sp_configure 'max degree of parallelism'

1.3 Database Options

Database Parameterization - Simple or Forced. The database parameterization option can have a significant impact on plan cache performance. It can be queried as follows:

select name, is_parameterization_forced from sys.databases

1.4 Workload Characteristics

Nature of the workload

(i) Query Mix: The type of the workload whether purely adhoc or stored procedures or a mix of adhoc and stored procedures can analyzed using:

select usecounts, cacheobjtype, objtype, bucketid

from sys.dm_exec_cached_plans cp

where cacheobjtype = 'Compiled Plan'

order by objtype

The objtype of 'adhoc' or 'proc' indicates the number of adhoc queries and stored procedure executions. Note that this query gives a snapshot of the plan cache at the time the query is executed. Prior to execution of this query, entries may have been removed from plan cache due to memory pressure.

(ii) Parameterization of Queries: From the above query if rows with objtype 'prepared' indicate that the queries are getting parameterized. If there are a large number of queries differing only in parameter values, the parameterized plan will have a high value for the usecounts column. If there are no parameterized queries, but many rows with objtype 'adhoc' then it indicates that queries are not getting parameterized.

(iii) Degree of Reuse of Plans: The usecounts column in the above query will indicate the degree of reuse of plans. If there are adhoc queries (shell queries) with a large usecounts this indicates that the exact same adhoc query is submitted several times for execution. If on the other hand the usecounts is close to 1 for adhoc queries this indicates a workload that has adhoc queries with almost no reuse. If the usecounts of the parameterized queries is low this may indicate incorrect client side parameterization. Several parameterized queries same query, but difference in data type of variables may indicate buckets of parameterized queries.

It is useful to gather all of the above information on SQL Server 2005 and SQL Server 2000 if you are seeing a performance regression upon upgrading to SQL Server 2005 (Note though that the scripts for SQL Server 2000 are different).

Number of Connections to SQL Server: The number of connections to sql server executing this workload.

CPU Utilization: The CPU utilization over the duration of the test workload can be monitored by capturing '%Processor Time\_Total' counter through logman. In the case of a multinode NUMA machine, it is important to capture CPU utilization per processor especially if a uniform affinity has not been set.

Throughput: Throughput can be measured as using the 'SQLServer:SQL Statistics\Batch Requests/sec' performance counter over the duration of the test workload. It is important to watch for fluctuations/degradations in throughput.

Plan Cache size and Database pages size: Collect 'SQL Server:Plan Cache\Cache Pages(_Total)' and 'SQLServer:BufferManager\Database pages' over the duration of the workload. This data will point out performance issues due to aggressive plan cache growth at the cost of keeping database pages in memory. It may also indicate that the max server memory setting may need to be increased to keep a more database pages in memory. It is useful to monitor these counters for both SQL Server 2005 and SQL Server 2000. This will help us understand if we are caching queries in SQL Server 2005 that we were not caching in SQL Server 2000, and what if any is the impact on throughput due to this additional caching.

12.0 Plan Cache Trace Events and Performance Counters

sangeethashekar — Fri, 19 Jan 2007 10:00:00 GMT

12.1 Trace Events

12.1.1 Performance Statistics Trace Event

The performance statistics trace event introduced in SQL Server 2005, gives persisted plan and runtime statistics information. With the information part of the trace event data when combined with the information available through the plan cache DMV sys.dm_exec_query_stats the performance history of any query can be reconstructed. The advantage of capturing this information via trace along with other plan cache trace events is that the trace data can be persisted by saving it to a trace file on the disk. The trace file contains a chronological list of trace events fired including query plans that can be analyzed for poor plans causing performance problems.

In SQL Server 2000, monitoring applications would have to capture SQL:BatchStarting, SQL:BatchCompleted and the ShowPlanXML events typically and analyze the trace data from all these events for performance problems. The batch starting and completed events are fired every time batch is executed and can be high volume events causing some performance degradation. In SQL Server 2005, the performance statistics trace event essentially obliterates the need to monitor these three different events. The trace data from the performance statistics trace event can be analyzed for poor plans causing performance problems. Performance statistics trace event is also a relatively lower volume trace (compared to the batch started and completed events) event since it is fired for unique queries and not every query.

The performance statistics trace event has 4 subclasses:

select distinct * from sys.trace_subclass_values

where trace_event_id = 165

and trace_column_id = 21

order by trace_event_id, subclass_value

Trace_event_id	Trace_column_id	Subclass_name	Subclass_value
165	21	SQL	0
165	21	SP:Plan	1
165	21	Batch:Plan	2
165	21	QueryStats	3

Sql batch text event (Subclass_name: SQL) is fired when sql text is inserted into the SQLMGR cache. This event subclass has batch scope; it fired once for every batch. The sql batch text event is not fired for object plans.

The object plan (Subclass_name: SP:Plan) and adhoc plan (Subclass_name: Batch:Plan) events are scoped at the statement level and are fired whenever the query is compiled or recompiled. They are not fired for queries with recompile hints. The adhoc plan events are fired only for DML and select queries and not for DDL, declare statements, while loop statements etc.

The run time stats event (Subclass_name: QueryStats) is fired when a compiled plan is removed from cache due to reasons including recompilation or memory pressure. The TextData column here contains the query execution statistics.

BOL has information regarding the trace event columns and how to interpret the trace data in the various columns for each even subclass.

Let us look at an example to see how to use performance statistics trace event:

Create a file trace with the performance statistics trace event (event id = 165) on the server:

Now suppose we have table that contains the all sales information and has three columns: transaction id, country id, and total_amount. The transaction id is the primary key column. In addition, the table has a non clustered index on the country id column. We also know that majority of the sales occur in country with id = 1, and country with id = 2 has far fewer rows in the sales table. If we had a stored procedure that reported sales by country id as below:

create proc sales_report @country_id int

as begin

select * from sales where country_id = @country_id

end

Now let us suppose this procedure is executed with parameter value 2 to generate the sales report for country id 2:

exec sales_report 2

The parameter value is sniffed in this case and we do an index seek (more details availbel in this previous posting).

Now consider the scenario where the system after achieving certain predictable performance for a period of time, now shows a sudden deterioration(an unexpected) in performance when the same stored procedure is re-executed with same parameter value (country id 2). Analyzing the performance statistics trace data in conjunction with the query statistics reported in sys.dm_exec_query_stats give important clues in understanding the reason for this unexpected drop in performance. Now let us check the DMVs to find get the query plan and the execution time statistics:

select total_worker_time/execution_count as avg_cpu_time,

substring(st.text, (qs.statement_start_offset/2) + 1,

((case statement_end_offset

when -1

then datalength(st.text)

else

qs.statement_end_offset

end

- qs.statement_start_offset)/2) + 1) as statement_text

, cast(query_plan as xml)

from sys.dm_exec_query_stats qs

cross apply sys.dm_exec_sql_text(qs.sql_handle) st

cross apply sys.dm_exec_text_query_plan(qs.plan_handle, qs.statement_start_offset, qs.statement_end_offset)

order by total_worker_time/execution_count desc;

Avg_

Cpu_

Time

Statement_

Text

Query_plan

126408

select * from sales where country_id = @country_id

<ShowPlanXML

PhysicalOp=

"Clustered Index Scan"

LogicalOp=

"Clustered Index Scan"

<ColumnReference

Column="@country_id"

ParameterCompiledValue="(1)" />

</ShowPlanXML>

From the query plan we can see that we are now doing an index scan and the sniffed parameter value is 1. This means the plan that was cached after the initial execution of the stored procedure with parameter value country id = 2 was probably removed from cache. Further, it a new plan for the stored procedure was inserted into cache, this time with parameter value country id = 2.

The performance statistics trace event data can confirm if indeed this was what happened. The stored procedure below analyzes the performance statistics trace data looking for object plans that are first inserted into cache and later deleted by matching the sql and plan handles. From the run time stats event, the average CPU time of the deleted plan is computed. The deleted query plan is obtained from the TextData column of the object plan event. The average CPU time of the new cached plan is computed from sys.dm_exec_query_stats. The query plan is available in sys.dm_exec_text_query_plan.

create procedure analyze_perf_stats_trace_data

begin

if object_id('trace_data', 'U') is not null

drop table trace_data;

if object_id('perf_stats_data_inserted', 'U') is not null

drop table perf_stats_data_inserted;

if object_id('perf_stats_data_deleted', 'U') is not null

drop table perf_stats_data_deleted;

if object_id('perf_stats_inserted_with_corresponding_deleted_object_events', 'U') is not null

drop table perf_stats_inserted_with_corresponding_deleted_object_events;

if object_id('perf_stats_deleted_with_corresponding_inserted_object_events', 'U') is not null

drop table perf_stats_deleted_with_corresponding_inserted_object_events;

if object_id('perf_stats_removed_plan', 'U') is not null

drop table perf_stats_removed_plan;

create table perf_stats_inserted_with_corresponding_deleted_object_events (TextData xml, EventClass int,

EventSubClass int, SqlHandle varbinary(64),

PlanHandle varbinary(64), StartTime datetime,

EventSequence int, PlanGenerationNumber bigint,

IntegerData2 int, Offset int);

create table perf_stats_deleted_with_corresponding_inserted_object_events (TextData xml, EventClass int,

EventSubClass int, SqlHandle varbinary(64),

PlanHandle varbinary(64), StartTime datetime,

EventSequence int, PlanGenerationNumber bigint,

IntegerData2 int, Offset int);

---read all the trace data from file

select * into trace_data from

::fn_trace_gettable ('c:\temp\perfstats.trc', default);

---select all rows corresponding to all object events

---cast the Sql and Plan Handle into varbinary(64)

select convert(xml, TextData) as TextData, EventClass,

EventSubClass, convert(varbinary(64), SqlHandle) as SqlHandle,

convert(varbinary(64), PlanHandle) as PlanHandle,

StartTime, EventSequence, BigintData1,

IntegerData2, Offset

into perf_stats_data_inserted

from trace_data

where EventClass = 165 and

EventSubClass = 1;

---select all rows corresponding to query stats events

---these events are generated when an plan is removed from cache

---for object and adhoc plans

select convert(xml, TextData) as TextData, EventClass,

EventSubClass, convert(varbinary(64), SqlHandle) as SqlHandle,

convert(varbinary(64), PlanHandle) as PlanHandle,

StartTime, EventSequence, BigintData1,

IntegerData2, Offset

into perf_stats_data_deleted

from trace_data

where EventClass = 165 and

EventSubClass = 3;

/* for every query statistics (plan deleted event) find the corresponding plan inserted events (object plans only). The plan inserted event should have lower event sequence number tha the QE stats event so we find plan insert events that occured earlier than the QE stats events. It should also have the

same plan handle as the QE stats event, statement start and end offset as the QE stats event. The QE stats and object plan events should also have the same plan generation number (bigintdata1). By matching plan generation numbers

we avoid duplicate rows from recompiles.

declare @TextData xml, @EventClass int, @EventSubClass int, @SqlHandle varbinary(64), @PlanHandle varbinary(64), @StartTime datetime, @EventSequence int, @PlanGenerationNum bigint,

@IntegerData2 int, @Offset int;

declare event_cursor cursor for select * from perf_stats_data_deleted;

open event_cursor;

fetch next from event_cursor into @TextData, @EventClass, @EventSubClass, @SqlHandle, @PlanHandle, @StartTime, @EventSequence, @PlanGenerationNum, @IntegerData2, @Offset;

while @@fetch_status =0

begin

insert into perf_stats_inserted_with_corresponding_deleted_object_events

select * from perf_stats_data_inserted where EventSequence < @EventSequence

and PlanHandle = @PlanHandle and BigIntData1 = @PlanGenerationNum

and IntegerData2 = @IntegerData2 and Offset = @Offset;

if exists(select * from perf_stats_data_inserted where EventSequence < @EventSequence

and PlanHandle = @PlanHandle)

insert into perf_stats_deleted_with_corresponding_inserted_object_events values(@TextData, @EventClass, @EventSubClass, @SqlHandle,

@PlanHandle, @StartTime, @EventSequence, @PlanGenerationNum, @IntegerData2, @Offset)

fetch next from event_cursor into @TextData, @EventClass, @EventSubClass, @SqlHandle,

@PlanHandle, @StartTime, @EventSequence, @PlanGenerationNum, @IntegerData2, @Offset;

end

close event_cursor;

deallocate event_cursor;

---compute the CPU time of the deleted plan from the QE stats

---event Text Data, plan handle, sql handle, and query plan that ---was removed and save the data into a table

select

d.TextData.value('(/QueryExecutionStats/WorkerTime/@Total)[1]', 'bigint') /

d.TextData.value('(/QueryExecutionStats/GeneralStats/@ExecutionCount)[1]', 'bigint')

as avg_cpu_time_removed,

i.TextData as query_plan_removed,

d.PlanGenerationNumber as plangenerationnum_removed,

d.PlanHandle as planhandle_removed,

d.SqlHandle as sqlhandle

into perf_stats_removed_plan

from

perf_stats_deleted_with_corresponding_inserted_object_events d, perf_stats_inserted_with_corresponding_deleted_object_events i

where i.PlanHandle = d.PlanHandle;

---note that plan generation numbers >2 indicate recompiles

select * from perf_stats_removed_plan;

/* Check if sys.dm_exec_query_stats has any rows with same Sql Handle and plan generation one greater than the deleted plan

If yes, get the CPU time, sql text, query plan, plan handle, sql handle compare results from this query with rows from perf_stats_removed_plan to indentify queries that are running slower */

declare @Sql_Handle varbinary(64), @PlanGenNum bigint;

declare event_cursor cursor for

select distinct sqlhandle, plangenerationnum_removed from perf_stats_removed_plan;

open event_cursor;

fetch next from event_cursor into @Sql_Handle, @PlanGenNum;

while @@fetch_status =0

begin

if exists(select * from sys.dm_exec_query_stats where sql_handle = @Sql_Handle and plan_generation_num <= @PlanGenNum + 1)

select total_worker_time/execution_count as avg_cpu_time_current,

substring(st.text, (qs.statement_start_offset/2) + 1,

((case statement_end_offset

when -1

then datalength(st.text)

else

qs.statement_end_offset

end

- qs.statement_start_offset)/2) + 1) as statement_text,

cast(query_plan as xml) as query_plan_current,

plan_generation_num as plan_generation_num_current,

plan_handle as planhandle_current,

sql_handle as sqlhandle

from sys.dm_exec_query_stats qs

cross apply sys.dm_exec_sql_text(qs.sql_handle) st

cross apply sys.dm_exec_text_query_plan(qs.plan_handle, qs.statement_start_offset, qs.statement_end_offset)

where qs.sql_handle = @Sql_Handle and

qs.plan_generation_num <= @PlanGenNum + 1 ;

fetch next from event_cursor into @Sql_Handle, @PlanGenNum;

end

close event_cursor;

deallocate event_cursor;

end

exec analyze_perf_stats_trace_data

The results returned by the stored procedure as below.

Avg_

cpu_

time_

Removed

Query_

Plan_

Removed

Plan

gene

ration

num_

removed

Plan

handle_

removed

Sql

Handle

229

<ShowPlanXML

PhysicalOp="Index Seek" LogicalOp="Index Seek"

Column="@country_id" ParameterCompiledValue="(2)" />

</ShowPlanXML>

0x050001

00894682

0FB8010C

05000000

00000000

0x030001

00894682

0F639506

01B89800

00010000

00000000

Avg_

cpu_

time_

current

Statement_

text

Query_

Plan_

current

Plan

gene

ration

num_

current

Plan

handle_

current

Sql

Handle

126408

select * from sales where country_id = @country_id

<ShowPlanXML

PhysicalOp=

"Clustered

Index Scan"

LogicalOp=

"Clustered

Index Scan"

Column=

"@country_id" Parameter

CompiledValue

="(1)" />

</ShowPlanXML>

0x050001

00894682

0FB8C118

05000000

00000000

0x030001

00894682

0F639506

01B89800

00010000

00000000

From the result set returned by the above stored procedure we can explain the slow down in execution time due to a new query plan. The plan handles are different while the sql handles are the same indicating we have a different plan for the exact same batch text. The plans before and after have a plan generation number of 1 indicating no recompiles occurred.

In the old query plan the parameter value was sniffed and we did an index seek to get all rows with country id 2. After the plan is deleted from cache (due to memory pressure or cache flush), the stored procedure is now executed with parameter value (country id = 1). The query plan does an index scan for sniffed parameter value 1. Now, when the stored procedure is executed with country id 2, we get poor performance because we re-use the cached plan which is not the optimal plan for country id 2.

Now let us look an example with recompiles:

create table t1 (a int, b int)

insert into t1 values (1, 1)

create procedure RowCountDemo

begin

declare @i int;

set @i = 0;

while (@i < 1000)

begin

insert into t1 values (@i, 2*@i - 50);

select a from t1 where a < 10 or ((b > 20 or a >=100) and (a < 10000)) group by a ;

set @i = @i + 1;

end

exec RowCountDemo

As described in this whitepaper, after 500 modifications to a table, any stored procedure referencing that table will need to be recompiled because the table statistics needs to be refreshed.

Now execute procedure analyze_perf_stats_trace_data and examine the result sets generated:

Avg_

cpu_

time_

Remo

ved

Query_

Plan_

Removed

Plan

gen

era

tion

num_

remo

ved

Plan

handle_

removed

Sql

Handle

3558

<ShowPlanXML

<RelOp

NodeId="0" PhysicalOp

="Sort" LogicalOp

="Distinct Sort"

</ShowPlanXML>

0x050001

0047E572

35B82199

04000000

00000000

0x030001

0047E572

35DD9000

01BA9800

00010000

00000000

Avg_

cpu_

time_

current

Statement_

text

Query_

Plan_

current

Plan

gene

ration

num_

current

Plan

handle_

current

Sql

Handle

insert into #t1 values (@i, 2*@i - 50);

<ShowPlanXML

<RelOp

NodeId="0" PhysicalOp=

"Table

Insert"

LogicalOp

="Insert"

</ShowPlanXML>

0x050001

0047E572

35B82199

04000000

00000000

0x030001

0047E572

35DD9000

01BA9800

00010000

00000000

1166

select a from #t1 where a < 10 or ((b > 20 or a >=100) and (a < 10000)) group by a ;

<ShowPlanXML

<RelOp

NodeId="1" PhysicalOp

="Table

Scan"

LogicalOp

="Table

Scan"

</ShowPlanXML>

0x050001

0047E572

35B82199

04000000

00000000

0x030001

0047E572

35DD9000

01BA9800

00010000

00000000

There are several things to note here:

1. Now the removed plan (from the query stats event) has a plan generation number of 1, while the current plan has a plan generation number of 2, and this indicates a recompile of the select query occurred. Also notice that both the sql and plan handles are the same because the query was recompiled.

2. A stored procedure can have several queries. For each one of these queries an object plan event is fired. To find the exact query that caused the recompile and therefore the query stats event to be fired, we would need to search for:

a. Object plan events that occurred earlier than the query stats event (i.e. object plan events with a lower EventSequence than the query stats events.

b. Object plan events that have the same plan handle as the query stats event.

c. Object plan events that have the same statement offsets (trace columns IntegerData2 and Offset) as the query stats event.

This would identify the object plan event corresponding to the query stats event.

12.1.2 Cache Hit, Miss, Insert and Remove Events

The SP:Cache Hit, Miss, Insert and Remove events are fired for compiled plans only. None of these events are part of the default trace. In this section we will describe briefly when these trace events are fired and changes made to plan cache trace events in SQL Server 2005.

It was observed that 99% of cases when a SP:Cache Miss event was fired, it was followed immediately by a SP:Cache Insert event with the exact same information. In the interest of keeping trace event volume low and eliminating duplicate trace information, in SQL Server 2005 we fire the SP:Cache Miss event only if the cache miss is not immediately followed by an cache insert. In other words, we defer the decision to fire the SP:Cache Miss event until we determine if we will fire an SP:Cache Insert event.

Consider a case when the compiled plan for the query below is not found in cache, and new compiled plan is inserted into cache:

select * from t1 where col1 = 5

TextData

Event

Class

Data

base

Data

base

Name

Object

Type

SPID

(@1 tinyint)SELECT * FROM [t1] WHERE [col1]=@1

SP:Cache

Insert

master

2573

0849

20816 - PQ

select * from t1 where col1 = 5

SP:Cache

Insert

master

9039

31361

20801 - AQ

When this query is executed for the first time, since a compiled plan for the query is not found in cache, the query is compiled and both the parameterized and the shell query are inserted into cache. In this case we fire the SP:Cache Insert event two times: once for the parameterized query and once for the shell query. Notice that we don’t fire the SP:Cache Miss event at all in this case. The firing of the SP:Cache Miss event is deferred until we determine whether or not to fire an SP:Cache Insert event. If we do fire the cache insert event, we will not fire the cache miss event. This optimization significantly reduces event volume without compromising on information we provide to the user via trace events. Another interesting thing to note here is that for prepared and adhoc compiled plans, the objectid column does not contain the ID of the object in the query as reported in sys.objects. It is a hash of the sql text. The DatabaseId column gives the id of the database from which the query was executed.

We adopt a similar strategy for stored procedures/functions as well as demonstrated in the example below:

exec sales_report @country_id = 2

TextData

Event

Class

Data

base

Data

base

Name

Object

Type

SPID

sales_report

SP:Cache

Insert

master

2636

71987

8272 - P

When a stored procedure is executed for the first time, the SP:Cache Insert event is fired and the text data of the trace event contains the stored procedure name, and not the entire body of the stored procedure. Notice that in this case too the SP:Cache Miss event is not fired. The object ID in this case is that of the stored procedure as reported in sys.objects.

Now let us consider an example where we will fire the SP:Cache Miss Event:

create table t1(col1 int primary key, col2 int, col3 int)

TextData

Event

Class

Data

base

Data

base

Name

Object

Type

SPID

create table t1(col1 int primary key, col2 int, col3 int)

SP:Cache

Miss

6993

70779

20801 - AQ

Certain DDL statements are not cached e.g. create table DDL. When the create table DDL is executed, we fire the SP:Cache Miss event because we are sure that it will not be followed immediately by a SP:Cache Insert event.

There are 2 conditions under which a compiled plan is removed from cache: memory pressure or procedure cache flush. In both these cases we fire the SP:Cache Remove event. In SQL Server 2005 we distinguish these two by providing different eventsubclasses for them: 1 - Compplan Remove, 2 - Proc Cache Flush. To help identify database operations flushing the plan cache in SQL Server 2005 SP2 an Errorlog event is fired with the following text data: "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". Note that the event if fired in 5 minute intervals as long as there was a cache flush operation in that time interval. For example:

dbcc freeproccache

TextData

Event

Class

Event

Sub

Class

Data

base

Data

base

Name

Object

Type

SPID

Entire Procedure Cache Flushed

SP:Cache

Remove

2 - Proc Cache Flush

master

Consider a case we query a table in an auto-close database which results in plan cache flush:

alter database test_db set auto_close on

select * from test_db.dbo.test_table

TextData	Event Class	Event Sub Class	Data base Id	Data base Name	SPID
Entire Procedure Cache Flushed	SP:Cache Remove	2 - Proc Cache Flush	1	master	18
2006-12-31 16:17:13.93 spid61 Setting database option AUTO_CLOSE to ON for database test_db.	ErrorLog		1	master	61
2006-12-31 16:17:14.24 spid18s SQL Server has encountered 1 occurrence(s) of cachestore flush for the 'Object Plans' cachestore (part of plan cache) due to some database maintenance or reconfigure operations.	ErrorLog		1	master	18
2006-12-31 16:17:14.24 spid18s SQL Server has encountered 1 occurrence(s) of cachestore flush for the 'SQL Plans' cachestore (part of plan cache) due to some database maintenance or reconfigure operations.	ErrorLog		1	master	18
2006-12-31 16:17:14.24 spid18s SQL Server has encountered 1 occurrence(s) of cachestore flush for the 'Bound Trees' cachestore (part of plan cache) due to some database maintenance or reconfigure operations.	ErrorLog		1	master	18

The SP:Cache Hit event is fired when we find the compiled plan and/or the MXC in the cache for query submitted for execution. If we find the MXC in the cache from previous execution, then we will fire SP:Cache Hit event with eventsubclass: 1- Execution Context Hit. For example:

select * from t1 where col1 = 5;

In this case, the after the first query is compiled the parameterized query is inserted into the cache. After query execution the execution context is as cached as well. Since the exact same query is re-executed and the execution context was cached, we get an execution context cache hit event.

TextData	Event Class	Event Sub Class	Data base Id	Data base Name	Object Id	Object Type	SPID
(@1 tinyint)SELECT * FROM [t1] WHERE [col1]=@1	SP:Cache Insert		1	master	2573 0849	20816 - PQ	58
select * from t1 where col1 = 5;	SP:Cache Insert		1	master	5610 17432	20801 - AQ	58
select * from t1 where col1 = 5;	SP:Cache Hit	1 - Exec ution Context Hit	1	master	5610 17432	20801 - AQ	58

If the MXC has been deleted due to memory pressure, or it was never cached, or if its not locally available on the same node in a multi-node machine, then we just fire the SP:Cache Hit event with Eventsubclass 2- Compplan Hit. For example:

select * from t1 where col1 = 5;

select * from t1 where col1 = 6;

In this case after the compilation of the first query the parameterized query is cached and this fires the cache insert event. For the second query in the batch we have a cache hit for the compiled plan but not an execution context hit since the parameter values are different in the second query.

TextData

Event

Class

Event

Sub

Class

Data

base

Data

base

Name

Object

Type

SPID

(@1 tinyint)SELECT * FROM [t1] WHERE [col1]=@1

SP:Cache

Insert

master

2573

0849

20816

- PQ

(@1 tinyint)SELECT * FROM [t1] WHERE [col1]=@1

SP:Cache

Hit

2 -

Comp

plan

Hit

master

2573

0849

20816

- PQ

The SP:Recompile and SQL:StmtRecompile trace event is discussed in this whitepaper. The plan cache related trace events and their different eventsubclasses can be found using:

select distinct * from sys.trace_subclass_values

where trace_event_id in (34, 35, 36, 37, 38)

and trace_column_id = 21

order by trace_event_id, subclass_value

Trace_ event_ id	Trace_ column_ id	Subclass_ name	Subclass_ value
36	21	Compplan Remove	1
36	21	Proc Cache Flush	2
37	21	Schema changed	1
37	21	Statistics changed	2
37	21	Deferred compile	3
37	21	Set option change	4
37	21	Temp table changed	5
37	21	Remote rowset changed	6
37	21	For browse permissions changed	7
37	21	Query notification environment changed	8
37	21	PartitionView changed	9
37	21	Cursor options changed	10
37	21	Option (recompile) requested	11
38	21	Execution Context Hit	1
38	21	Compplan Hit	2

12.2 Performance Counters

Plan cache counters defined in SQL Server 2005 include Cache Hits Ratio, Cache Pages, Cache Objects Count, and Cache Objects in Use. Plan cache performance counters in SQL Server 2005 are available under the performance object ‘SQLServer: Plan Cache’. The plan cache performance counters have one instance for each of five cache stores: Bound Trees, Extended Stored Procedures, Object Plans, Sql Plans and Temporary Tables and Table Variables and one additional _Total instance. In other words, in SQL Server 2005 we now report hit ratio, cache pages, object counts etc per cache store instead of the individual types of cached objects.

Examine the SQL Plans and Object Plans instances of the Cache Hit Ratio counter to see if compiled plans are being re-used. Low cache hit ratio (<20%) along with a sustained query execution rate (SQLServer: SQL Statistics\Batch Requests/sec) indicates that compiled plans are not being re-used. It should be noted that the hit ratio counter may be skewed by internal lookups performed.

The Cache Pages counter is useful counter to watch when performance degradation observed on the server. For a workload with adhoc queries, typically the database pages increase along with the plan cache pages. It in SQL Server 2005 RTM And SP1 since the plan cache can grow to about ~80% of the buffer pool without being under memory pressure, this would leave very little room for database pages. This results in the database pages being evicted and subsequent performance degradation. To verify if this is indeed what is happening track the following performance counters: 'SQL Server: Plan Cache\Cache Pages(_Total)' and 'SQLServer: BufferManager\Database pages' and look for a significant decrease in the database pages counter as the plan cache pages counter increases and reaches the threshold value after which memory pressure sets in. This problem has been addressed in SQL Server 2005 SP2 by limiting the cache store sizes (more details will be available in blog post titled ‘Improvements made to Plan Cache behavior in SQL Server 2005 SP2’). Other potential solutions would be to reduce the amount of caching by examining the workload to see if queries have been parameterized, or can be rewritten with stored procedures.

Other performance counters that provide useful plan cache related information include SQL Server:SQL Statistics\Unsafe Auto-Params/sec. An increment in the SQL Server:SQL Statistics\Unsafe Auto-Params/sec performance counter indicates that the query was unsafe auto-parameterized. Likewise the counters SQL Server: SQL Statistics\Forced Parameterizations/sec and SQL Server: SQL Statistics\Safe Auto-Params/sec give then rate of forced parameterizations and safe auto parameterizations.

The counters SQLServer: SQL Statistics\SQL Compilations/ sec and SQLServer: SQL Statistics\SQL Re-Compilations/ sec give the number of compilations and recompilations per second. In order to benefit from caching, ideally the rate of compilations and recompilations should be low.

One additional thing to note here is that queries compiled with a RECOMPILE hint are not actually considered recompiles. The word recompile in these hints is a misnomoer because the new plan is generated before query execution begins these would more accurately be classified as compiled and not recompiles. Hence we see an increment in the SQL Server:SQL Statistics\SQL Compilations/sec counter and not the SQL Server: SQL Statistics\SQL Re-compilations/sec counter. Consider the example below: Sales table has three columns: transaction id, country id, and total_amount. We also know that majority of the sales occur in country with id = 1, and country with id = 2 has far fewer rows in the sales table. If we had a stored procedure that reported sales by country id as below:

create proc sales_report @country_id int

as begin

select * from sales where country_id = @country_id

end

If we now executed the stored proc with country id 2 first, then the query_plan chosen based on parameter sniffing is a sub-optimal plan for country id 1. To avoid parameter sniffing, we could adopt one of three approaches:

Approach 1: Create the procedure by adding WITH RECOMPILE to stored procedure definition as below.

create proc sales_report @country_id int with recompile

as begin

select * from sales where country_id = @country_id

end

Before taking approach one, evaluate if the compilation time of the stored procedure is relatively small because this approach would mean compilation of all queries inside the stored procedure. Also the compiled plan is not inserted into cache.

Approach 2: Add the WITH (RECOMPILE) hint to the query inside the stored procedure

create proc sales_report @country_id int

as begin

select * from sales where country_id = @country_id option (recompile)

end

Before taking approach two, evaluate if additional compilation time of the query relative to the execution time savings is relatively small then this approach is may provide the more suitable solution.

Approach 3: Execute the stored procedure WITH RECOMPILE.

Approach 3 implies a new plan will be compiled for every execution of the stored procedure. The compiled plan generated will not be inserted into cache. However, a previously cached plan for the stored procedure will not be removed.

exec sales_report @country_id = 2 with recompile

For all three approaches, the compilations counter is incremented, and not the recompilations counter.

11.0 Temporary Tables, Table Variables and Recompiles

sangeethashekar — Thu, 18 Jan 2007 10:00:00 GMT

11.1 Temporary Tables versus Table Variables

In order to determine if table variables or temporary tables is the best fit for your application, let us first examine some characteristics of table variables and temporary tables:

1. Table variables have a scope associated with them. If a table variable is declared in a stored procedure, it is local to that stored procedure and cannot be referenced in a nested procedure.

2. The transaction semantics for table variables is different from temporary tables. Table variables are not affected by transaction rollbacks. Every operation on a table variable is committed immediately in a separate transaction.

3. It is not possible to create indexes on table variables except by specifying them as constraints (primary key and unique key). In other words, no DDL is possible on table variables. On the other hand, it is possible to create non key indexes on temporary tables. This is especially useful if the data set is large.

4. Temporary tables can also be referenced in nested stored procedures and may be the right fit if the object needs to be available for a longer duration (not just scoped to the batch like table variables).

5. Both temporary tables and table variables are kept in memory until their size reaches a certain threshold after which they are pushed to disk.

Let us examine the caching impact of temporary tables and table variables. There are no statistics based recompiles for table variables. The general rule of thumb is to use temporary tables when operating on large datasets and table variables for small datasets with frequent updates. Consider the example below where the table test_table has 10 rows of data and 100K rows are inserted into a table variable. Then a join is performed on the table variable and test_table.

create procedure table_variable_proc

begin

declare @table_variable table(col1 int, col2 varchar(128));

declare @i int;

set @i = 0;

while (@i < 100000)

begin

insert into @table_variable values(@i, convert(varchar(128), @i));

set @i = @i + 1;

end

select * from @table_variable tv join test_table on tv.col1 = test_table.col1;

end

exec table_variable_proc

Now let us rewrite the same example with temporary tables to compare and contrast the two approaches:

create procedure temp_table_proc

begin

create table #table_name(col1 int, col2 varchar(128));

declare @i int;

set @i = 0;

while (@i < 100000)

begin

insert into #table_name values(@i, convert(varchar(128), @i));

set @i = @i + 1;

end

select * from #table_name join test_table on #table_name.col1 = test_table.col1;

end

exec temp_table_proc

Now query the DMVs to get the query plan and average CPU time:

select total_worker_time/execution_count as avg_cpu_time,

substring(st.text, (qs.statement_start_offset/2) + 1,

((case statement_end_offset

when -1

then datalength(st.text)

else

qs.statement_end_offset

end

- qs.statement_start_offset)/2) + 1) as statement_text

, cast(query_plan as xml)

from sys.dm_exec_query_stats qs

cross apply sys.dm_exec_sql_text(qs.sql_handle) st

cross apply sys.dm_exec_text_query_plan(qs.plan_handle, qs.statement_start_offset, qs.statement_end_offset)

order by total_worker_time/execution_count desc;

Avg_

Cpu_

Time

Statement_

Text

Query_plan

208412

select * from @table_variable tv join test_table on tv.col1 = test_table.col1;

<ShowPlanXML xmlns="http://

schemas.microsoft.

com/sqlserver/2004/07/showplan"

Version="1.0" Build="9.00.0000.00">

<Batch>

<StmtSimple StatementText=

"create procedure

table_variable_proc

<QueryPlan CachedPlanSize="8"

CompileTime="2" CompileCPU="2"

CompileMemory="120">

<RelOp NodeId="0"

PhysicalOp="Nested Loops"

LogicalOp="Inner Join"

EstimateRows="1" EstimateIO="0"

</ShowPlanXML>

51978

select * from #table_name join test_table on #table_name.col1 = test_table.col1;

<ShowPlanXML xmlns="http://

schemas.microsoft.

com/sqlserver/2004/07/

showplan" Version="1.0"

Build="9.00.0000.00">

<Batch>

<StmtSimple StatementText=

"
create procedure

temp_table_proc

<QueryPlan CachedPlanSize="21"

CompileTime="322"

CompileCPU="203"

CompileMemory="104">

<RelOp NodeId="0"

PhysicalOp="Hash Match"

LogicalOp="Inner Join"

EstimateRows="10"

</ShowPlanXML>

The temporary tables query outperforms the table variables query. Notice that the query plan for the table variables query estimates 1 row at compile time and therefore chooses a nested loop join. In the temporary tables case, however, the query plan chosen is a hash join which leads to better query performance. Since the query plan for table variables always estimates the number of rows at compile time to be zero or one, table variables may be more suitable when operating on smaller datasets.

11.2 Recompiles Based on Temporary Tables

Recompiles of queries with temporary tables occur for several reasons and can cause poor performance if temporary tables are not used properly. Using examples we will look at the most common causes for recompiles based on temporary tables. Consider the example below:

create procedure DemoProc1

begin

create table #t1(a int, b int);

insert into #t1 values(1,2);

select * from #t1;

end

Enable the SP:Recompile and SP:StmtRecompile events in profiler.

exec DemoProc1

TextData	EventClass	EventSubClass
insert into #t1 values(1,2);	SP:Recompile	3 - Deferred compile
insert into #t1 values(1,2);	SQL:StmtRecompile	3 - Deferred compile
select * from #t1;	SP:Recompile	3 - Deferred compile
select * from #t1;	SQL:StmtRecompile	3 - Deferred compile

When the stored procedure DemoProc1 is compiled, the insert and select query are not compiled. This is because during initial compilation, the temporary table does not exist and the compilation of this query is deferred until execution time. A compiled plan for the stored procedure is generated, but is incomplete. At execution time, the temporary table is created, and the select and insert statement are compiled. Since the stored procedure is already in execution, this compilation of the select and insert query are classified as a recompilation. It is important to note that in SQL Server 2005, only the select and insert statement in the stored procedure are recompiled. In SQL Server 2000, the entire stored procedure is recompiled. Subsequent re-executions of this stored procedure do not result in any more recompiles since the compiled plan is cached. Notice that even though the temporary table is re-created each time the stored procedure is executed, we do not recompile the stored procedure each time. This is because the temporary table is referenced in the plan by name and not by ID if they are created in the same module. Since the temporary table is re-created each time with the same name, the same compiled plan is re-used. Now consider a case when the temporary table is referenced in a second stored procedure as below:

create procedure DemoProc1

begin

create table #t1(a int, b int);

insert into #t1 values(1,2);

exec DemoProc2;

end

create procedure DemoProc2

begin

select * from #t1;

end

Now enable the SP:Recompile and SP:StmtRecompile events in profiler.

exec DemoProc1

TextData	EventClass	EventSubClass
insert into #t1 values(1,2);	SP:Recompile	3 - Deferred compile
insert into #t1 values(1,2);	SQL:StmtRecompile	3 - Deferred compile
select * from #t1;	SP:Recompile	1 – Schema Changed
select * from #t1;	SQL:StmtRecompile	1 – Schema Changed

Each execution of DemoProc1 leads to recompiles of the select statement. This is because the temporary table is referenced by ID in DemoProc2 since the temporary table was not created in the same stored procedure. Since the ID changes every time the temporary table is created, the select query in DemoProc2 is recompiled.

Now let us make a slight variation to DemoProc1 as illustrated below:

create procedure DemoProc1

begin

create table #t1(a int, b int);

insert into #t1 values(1,2);

exec DemoProc2;

end

create procedure DemoProc2

begin

select * from #t1;

end

exec DemoProc1

Notice that the second execution of DemoProc2 inside DemoProc1 causes no recompiles. This is because we already have the cached query plan the select query on the temporary table and it can be re-used because the temporary table ID is the same.

It is important to group together all DDL statements (like creating indexes) for temporary tables at the start of a stored procedure. By placing these DDL statements together unnecessary compilations due to schema change can be avoided. Some other common reasons for recompiles relating to temporary tables include: declare cursor statements whose select statement references a temporary table, or in an exec or sp_executesql statement.

One of the most common reasons for recompiles of queries with temporary tables is row count modification. Consider the example below:

create procedure RowCountDemo

begin

create table #t1 (a int, b int);

declare @i int;

set @i = 0;

while (@i < 20)

begin

insert into #t1 values (@i, 2*@i - 50);

select a from #t1 where a < 10 or ((b > 20 or a >=100) and (a < 10000)) group by a ;

set @i = @i + 1;

end

Before executing the stored procedure enable the SP:Recompile and SP:StmtRecompile events in profiler.

exec RowCountDemo

The trace event data is as follows:

TextData

EventClass

EventSubClass

select a from #t1 where a < 10 or ((b > 20 or a >=100) and (a < 10000)) group by a ;

SP:Recompile

2 - Statistics changed

select a from #t1 where a < 10 or ((b > 20 or a >=100) and (a < 10000)) group by a ;

SQL:StmtRecompile

2 - Statistics changed

After 6 modifications to an empty temporary table any stored procedure referencing that temporary table will need to be recompiled because the temporary table statistics needs to be refreshed.

The recompilation threshold for a table partly determines the frequency with which queries that refer to the table recompile. Recompilation threshold depends on the table type (permanent vs temporary), and the cardinality (number of rows in the table) when a query plan is compiled. The recompilation thresholds for all of the tables referenced in a batch are stored with the query plans of that batch.

Recompilation threshold is calculated as follows for temporary tables: n is the cardinality of the temporary table when the query plan is compiled.

If n < 6, Recompilation threshold = 6.

If 6 <= n <= 500, Recompilation threshold = 500.

If n > 500, Recompilation threshold = 500 + 0.20 * n.

For table variables recompilation thresholds do not exist. Therefore, recompilations do not happen because of changes in cardinalities of table variables.

10.0 Plan Cache Flush

sangeethashekar — Wed, 17 Jan 2007 10:00:00 GMT

In SQL Server 2005, certain database maintenance operations or certain dbcc commands such as “dbcc freeproccache” or “dbcc freesystemcache” will clear the plan cache for the instance of SQL Server. Clearing the plan cache causes a recompilation of all subsequent execution plans and cause a sudden, temporary excessive CPU usage and decrease in query performance. To help identify database operations flushing the plan cache as the cause of the sudden temporary decrease in query performance, SP2 includes an informational message in the 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". This message is logged every five minutes as long as the cache is flushed within that time interval.

The following database operations will flush the plan cache:

When the database is set to AUTOCLOSE = ON, an operation that initiates an automatic database shutdown clears the plan cache for the instance of SQL Server.
ALTER DATABASE [dbName] SET ONLINE
ALTER DATABASE [dbName] SET OFFLINE
ALTER DATABASE [dbName] SET READ_ONLY
ALTER DATABASE [dbName] SET READ_WRITE
ALTER DATABASE [dbName] MODIFY NAME = [SomeDB_Name]
ALTER DATABASE [dbName] MODIFY FILEGROUP Test1FG1 DEFAULT
ALTER DATABASE [dbName] MODIFY FILEGROUP Test1FG1 READ_WRITE
ALTER DATABASE [dbName] MODIFY FILEGROUP Test1FG1 READ_ONLY
ALTER DATABASE [dbName] COLLATE Collation_Name
DROP DATABASE [db_Snapshot_Name]
Restore database operation
Detach database operation
DBCC FREEPROCCACHE
DBCC FREESYSTEMCACHE

In SQL Server 2005 RTM and SP1, executing DBCC CHECKDB clears the plan cache for the instance of SQL Server. In SP2, executing DBCC CHECKDB does not clear the plan cache.

9.0 Memory Pressure Limits

sangeethashekar — Tue, 16 Jan 2007 10:00:00 GMT

The procedure cache responds to memory pressure like all other cache stores built using the common caching framework. The eviction of cache entries under memory pressure is based on the cost of the entry (plan). When memory pressure conditions are reached, in one clock round zero cost entries are removed from the cache store and the cost of other entries reduced (by a factor of two). This is a standard least recently used (LRU) algorithm.

There two types of memory pressure conditions in response to which entries are removed form cache stores: local and global memory pressure.

9.1 Local Memory Pressure

If a particular cache store grows too big, then it is flagged for reaching local memory pressure limits and entries are removed from this cache store. Entries are not removed from other cache stores. This is done to prevent one cache store from consuming all of the system memory. The conditions for reaching local (internal) memory pressure are described below:

The following table shows how the maximum limit of the plan cache is determined for each version of SQL Server:

SQL Server Version	Cache Pressure Limit
SQL Server 2005 RTM & SP1	75% of visible target memory from 0-8GB + 50% of visible target memory from 8Gb-64GB + 25% of visible target memory > 64GB
SQL Server 2005 SP2	75% of visible target memory from 0-4GB + 10% of visible target memory from 4Gb-64GB + 5% of visible target memory > 64GB
SQL Server 2000	SQL Server 2000 4GB upper cap on the plan cache

If the cache store reaches 75% of the cache store size limit (as per the table above) in single page allocations or 50% of the limit in multi-page allocations, this triggers internal memory pressure conditions and removal of entries from the cache store. On 32 bit systems, cache store size is determined based on the visible target memory (up to 3GB). On 64 bit systems the server memory is determined based on the max server memory settings.

If upon the insertion of an entry into the cache store internal memory pressure conditions are reached, then entries are deleted from the cache store on the same thread synchronously. This may cause the response time of that query that was inserted in to the cache store to be large.

The default number of entries updated in one clock hand move (before we re-check to see if internal memory pressure still persists) is 16 when internal memory pressure is signaled. We may remove up to the number of updated entries if all those entries were zero-cost. Upon removing 16 entries from the cache store if internal memory pressure conditions still persist, in the next notification 32 entries (double the number of entries removed in the previous notification cycle, up to a maximum of 1024 entries) are removed.

Another condition that signals internal memory pressure for the cache stores is if the number of entries in the cache store becomes greater than 4 times the hash table size. The hash table size can be obtained using the following query:

select buckets_count from sys.dm_os_memory_cache_hash_tables

where type in ('CACHESTORE_OBJCP' , 'CACHESTORE_SQLCP', 'CACHESTORE_PHDR', 'CACHESTORE_XPROC')

On a 32 bit system, if the SQLCP cache store had more than approximately 40,000 entries or on a 64 bit system the cache store had more than 160,000 entries, this would trigger internal memory pressure conditions on the cache store and removal of entries. Examine the sys.dm_os_memory_cache_clock_hands DMV to see if the internal clock hand is moving for the SQLCP cache store.

select * from sys.dm_os_memory_cache_clock_hands where type = 'CACHESTORE_SQLCP'

9.2 Global Memory Pressure

When the system reaches external memory pressure conditions, then entries are removed from all cache stores based on their cost. There are several conditions that can signal external memory pressure as described below:

Global External Memory Pressure: This condition occurs when there are several processes including sqlservr.exe running on the machine, and the operating system determines that sqlservr.exe needs to shrink its memory consumption. Since this is a global condition all cache stores are shrunk in response to the signal from the operating system.

Global Internal Virtual Memory Pressure: This condition is more likely on 32 bit systems where there is limited virtual address space. If there are a large number of multi page allocations made, it is likely that we may be low on available virtual address space. This shortage of virtual address space gets propagated to the resource monitor, which in turn signals all cache stores to shrink.

Global Internal Memory Pressure: There are 2 conditions when memory broker signals global internal memory pressure based on single page allocations only:

If the predicted usage of memory by all cache stores (as predicted by the cache memory broker) reaches 80% of the visible memory, then global internal memory pressure is signaled. In response to this condition, entries are removed from all cache stores.
The memory broker maintains an account of how much memory is allocated to cache stores, query optimizer and for query execution (reserved pages). It also maintains the rate of growth of each of these components and predicts future allocations (for an interval of 4 seconds). The overall target memory allocation should be less than 80% of the visible buffer pool at all times. Therefore if the predicted and the current usage is less than this over all target, then all components including caches can continue to grow. New targets for growth are computed for each component and broadcast. If the current memory usage of that component is higher than the new target, a shrink notification is sent. If the current memory usage of that component is lower than the new target, that component can continue to grow cautiously keeping the target value in perspective. Consider for example if the cache stores are big in comparison to the memory allocated for query optimizer or query execution, and the projected rate of growth of the query optimizer is high, and that of the cache stores is low, then the cache stores will be shrunk to make memory available for the query optimizer.

The default number of entries updated in one notification cycle is 16 for every cache store when external memory pressure is signaled. If the updated entries are zero-cost then they are removed.

If one of the cache stores is empty, then the number of unused entries is added to a global pool of unused entries. We would have had to update up to 16 entries if the cache store was not empty. These entries that we did not have to update because the cache store was empty are referred to as unused entries and are added to a global pool of unused entries. Now when we encounter the next non-empty cache store, we can update up to 16 plus the number of number of unused entries available in the global pool of unused entries. In other words we apply the gain from not having to delete entries from an empty cache store to the next cache store that has entries to be removed. For example, if there was one empty cache store followed by a large non empty cache store, the global pool of unused entries would have 16 entries now. Therefore we can update up to 32 entries (16 + 16 unused from global pool) in the next non empty cache store. This helps prune large cache stores faster especially in scenarios where there are several small cache stores, and one large cache store.

Note that both under internal and external memory pressure conditions there is no mechanism to free memory from entries that are currently in use or remove these entries entirely. However it is still possible that these entries may have memory that can be returned to the system under memory pressure conditions. The two compiled plan cache stores (SQLCP and OBJCP) have compiled plan entries that have dependant objects such as MXCs, XStmts and cursors. These two cache stores implement a mechanism to reclaim half the memory from these dependant objects (MXCs, XStmts and cursors) even if these entries are in use. Note that the dependent objects are re-generate-able cache entries, and are fairly inexpensive to regenerate compared to compiled plans. It is therefore not as valuable to keep them in cache especially under memory pressure conditions.

8.0 Factors that Affect Batch Cache-ability

sangeethashekar — Mon, 15 Jan 2007 10:00:00 GMT

During batch compilation we make a determination regarding the cache-ability of the batch. Each statement in the batch is evaluated either as not-cacheable, cacheable, cache even though zero cost, set cost on re-use or not-cacheable due to sensitive information. A batch is marked cacheable if at least one statement in the batch is cacheable.

If a batch contains one statement that contains sensitive information, then the statement is marked not cacheable due to sensitive information. The batch however may have other statements that are evaluated as cacheable, but the presence of even one statement that is marked not cacheable due to sensitive information deems the entire batch not cacheable. Examples of statements that contain sensitive information include: Create/Alter App Role, Create/Alter Login, Create/Alter Credential, Create/Alter/Dump Certificate, Create/Alter/Open Symmetric Key, Create/Alter Asymmetric Key, Create/Alter/Backup/Restore/Open Master Key, Alter/Backup/Restore Service Master Key, Add/Drop Signature and Alter Database. This is important factor to keep in mind when writing application code, because batches that contain such statements cannot benefit from plan re-use.

DDL statements are marked not cacheable, because we expect these statements to be infrequent and to recompile. Therefore if a batch was composed entirely of DDL statements, then the batch is marked not cache-able. There are exceptions however to account for temporary tables DDL operations that are frequent and would benefit from DDL statement caching. Another exception includes drop DDL statements. These statements are marked cacheable. The full exception list includes: Create/Drop Table, Create/Drop Index, Create/Drop Stats, Drop Procedure, Drop Function, Drop View, Drop Rule, Drop Default, Drop Trigger, Drop Aggregate, Drop Synonym and Update Stats.

Sometimes a significant benefit can come from caching batches that evaluate to a zero cost. One such example would be driver generated queries like “SET ANSI_NULLS ON” that are issued every time we make a connection to the server. Often times the driver generated queries are single statement batches that evaluate to a zero cost. We mark such statements cache even though zero cost. Also cursor select, api cursor fetch, queries (DML + select) statements are marked cache even though zero cost.

Now it is interesting to see how these statements (marked cache even on zero cost) when combined with DDL statements without or without sensitive information (marked not cacheable) affect the cache-ability of the batch. If the batch has one statement marked not cacheable due to sensitive information, then the batch is not cached. If the batch has DDL statements without sensitive that are marked not cacheable, and statements marked cache even on zero cost, then the batch is cached.

In SQL Server 2005 RTM and Sp1, a set options statement or transaction statements would be marked as cache even though zero cost, and therefore almost always causing the entire batch to be cached. In SQL Server 2005 Sp2 however, unless the batch was entirely composed of set statements or transaction statements or if statements the batch is not cached if it evaluates to a zero cost.

Shell queries corresponding to parameterized (simple and forced) are marked cache-able even if they are zero cost. These queries are inserted into the cache with a zero cost, and on first re-use their cost is set to the original cost. Applications that re-execute the same query (including parameter value) will benefit from caching of shell queries. For other applications that do not re-use the same query, since shell queries are inserted with a zero cost these will be the first candidates for removal from the caches when memory pressure conditions are reached. Note that insert shell queries are never cached. This is because the probability of re-use of the exact same insert query is low.

All other queries are evaluated for cache-ability based on their cost. If a batches needs to use blobs or if the batch has a procedure marked with the recompile option then the batch is marked not cache-able.

7.0 Costing Cache Entries

sangeethashekar — Sun, 14 Jan 2007 10:00:00 GMT

A uniform costing scheme has been implemented for all cache stores in SQL Server 2005. The cost of a query depends on 3 factors: number of disk IO requests, number of context switches during query compilation (in 4 ms quantums) and the number of memory pages, both from single and multi-page allocations. In SQL Server 2005, the original cost of the query is a power of two, the exponent being the sum of the contributions of disk IO’s, context switches and memory pages to the cost.

Mathematically:

Cost = 2 ^{min (IO > 0 ? (IO - 1) / 2 + 1 : 0, 19) + min (CS > 1 ? (CS - 1) / 2 + 1 : 0, 8) + min (MP / 16, 4)}

Where

IO - the number of IO requests (regardless of the number of bytes involved),

CS - the number of context switches, i.e. the number of 4 ms quantums,

MP - the number of memory pages (from both single and multi page allocations)

The contribution of context switches is as follows: for queries with zero or one context switches, the contribution is zero. For queries with number of context switches two, the contribution is one. For every two context switches over two, the contribution increases by one up to a maximum of eight. The disk IO’s contribution is zero if the number of disk IO’s is zero. For every two disk IO’s over zero, the contribution increases by one up to a maximum of nineteen. The contribution from memory pages is the number of pages divided by sixteen up to a maximum of four. In other words every 128KB contribute one up to 512 KB. To illustrate with an example: if a query has zero disk IO’s, four context switches, and 2 memory pages, then original cost is 2 (0 + 2 + 0) = 4.

To obtain the original and the current cost of a cached entry use the query below:

select text, usecounts, original_cost, current_cost, disk_ios_count, context_switches_count, pages_allocated_count

from sys.dm_exec_cached_plans cp cross apply sys.dm_exec_sql_text(plan_handle) st

join sys.dm_os_memory_cache_entries ce

on cp.memory_object_address = ce. memory_object_address

The pages_allocated_count in the above query includes the compile time and the execution time memory as well. The contribution of memory to the cost of the query is based only on the compile time memory. The cost of a query is non deterministic due to the dependency of the cost on disk IO’s and the number of context switches. If the system is heavily loaded, the contribution of the number context switches can potentially be very much higher than if the same query was compiled when the system was not heavily loaded. The contribution of disk IO’s can also be high when there are no entries in the meta data cache causing meta data cache lookups from disk.

In order to avoid potential flooding of the plan cache some heuristics have been put in place to make a decision regarding the cache-ability of a plan after the cost is computed. Adhoc complied plans that are evaluated to a zero cost are not cached. Adhoc compiled plan entries are inserted into the cache with a cost of zero regardless of their original cost (as computed using the above formula). Their cost is re-set to their original cost on first re-use. Since in most cases it is not likely that these adhoc compiled plans will be re-used we set their cost to zero making them the first candidates for removal under memory pressure conditions. The maximum cost of these entries is 4, and therefore they can survive up to a maximum of 2 clock rounds under memory pressure conditions. Prepared compiled plans are inserted with their original cost, and they can survive up to 8 rounds under memory pressure before they are evicted from cache making their maximum cost 256. Entries in the OBJCP cache store are inserted with their original cost since they are highly reuse-able making it valuable to cache them.

6.0 Best Programming Practices

sangeethashekar — Sat, 13 Jan 2007 10:00:00 GMT

In this section we will outline some programming practices for efficient plan cache usage:

6.1 Client Side Parameterization of Queries

If your application has repeated execution of the same query with only parameter values changing from query to another, then parameterizing the query in the client application code before execution gives some significant performance gains. The performance gains come from the fact that the query is compiled just once versus once for every query issued for execution. Prepared execution also provides advantage from the fact that it helps reduce network traffic by eliminating the need to send the sql query text to the server each time. In cases where the statement text is fairly large the cost of transmitting this text from client to server repeatedly can quickly add up. In the case of prepared execution however all that needs to be sent over the network are parameter values, and the prepared handle (there is a list of prepared handles in a session). The prepared handle has the hash value associated with the query text which needs to be computed only once (versus once per query execution). Also since the server does not do any parameterization, there is no chance for plan cache bloating due to caching the shell queries.

Client side parameterization if applied incorrectly can cause more grief than gain. Since the server cannot parameterize the queries, and the advantage of simple or forced parameterization is lost. We will try to illustrate some of the common mistakes made, and also recommend some best practices. Consider the example below where the client code relies entirely on server side parameterization:

command.CommandText = "select * from t1 where col1 = 1 and col2 = 'abcd'";

command.ExecuteNonQuery();

command.CommandText = "select * from t1 where col1 = 1 and col2 = 'abc'";

command.ExecuteNonQuery();

This results in one parameterized plan:

(@1 tinyint,@2 varchar(8000))SELECT * FROM [t1] WHERE [col1]=@1 AND [col2]=@2

Notice that in the absence of any client side parameterization, the server side forced bucketization applies. All queries are bucketized to varchar(8000) or nvarchar(4000). If the parameter is greater than varchar(8000) then nvarchar(max) is used. While this may seem acceptable, if the parameter data is always limited to say 50 characters (limited by the column data type and length) then it is not an optimal solution. Now consider the example below where the query has been parameterized incorrectly:

command.CommandText = "select * from t1 where col1 = @id and col2 = @str";

command.Parameters.Add("@id", 1);

command.Parameters.Add("@str", "abc");

command.ExecuteNonQuery();

command.Parameters[0].Value = 2;

command.Parameters[1].Value = "abcd";

command.ExecuteNonQuery();

This results in two parameterized queries:

(@1 tinyint,@2 varchar(3))SELECT * FROM [t1] WHERE [col1]=@1 AND [col2]=@2

(@1 tinyint,@2 varchar(4))SELECT * FROM [t1] WHERE [col1]=@1 AND [col2]=@2

Since the parameter type and lengths are not specified, different parameter values lengths can potentially generate different parameterized plans. This can cause a significant performance degradation in SQL Server 2005 RTM and SP1 since all these parameterized queries will hash into the same hash bucket. The reason they all hash into the same bucket is because they have the exact same parameterized query text but for the declarations, and the hash value is only computed in SQL Server 2005 and RTM based on the parameterized query text not including the declarations.

For legacy applications where change to client side code is not an option, use TF 144 to force server side bucketization. When the application has queries that are improperly parameterized, this trace flag forces server side bucketization. This will result in only one parameterized plan:

(@1 tinyint,@2 varchar(8000))SELECT * FROM [t1] WHERE [col1]=@1 AND [col2]=@2

Note however this a server wide option and will apply to all parameterized queries executed. In some cases this may not be suitable, and hence we advise use of this trace flag with caution.

The recommended method to parameterize queries in client application code has been illustrated below:

SqlConnection connection = new SqlConnection ("context connection = true");

connection.Open();

SqlCommand command = connection.CreateCommand();

command.CommandText = "select * from t1 where col1 = @id and col2 = @str";

command.Parameters.Add("@id", SqlDbType.Int);

command.Parameters.Add("@str", SqlDbType.VarChar, 50);

command.Parameters[0].Value = 1;

command.Parameters[1].Value = "abc";

command.ExecuteNonQuery();

command.Parameters[0].Value = 2;

command.Parameters[1].Value = "abcd";

command.ExecuteNonQuery();

This results in only one prepared compiled plan for both executions for the select query:

(@id int,@str varchar(50))select * from t1 where col1 = @id and col2 = @str

Some key points to note here include that we have parameterized the query and carefully specified the data type and the max length for the parameters (we specify the max length of the varchar parameter the same as the table column data type). Note that the query optimizer will try to ‘sniff’ parameter values and choose an optimal plan appropriately. While in most cases this works to our advantage, in some cases where the first parameter values are atypical it can actually cause a suboptimal plan to be chosen.

We can still do one better than the example above by deferring query preparation to execution time:

command.CommandText = "select * from t1 where col1 = @id and col2 = @str";

command.Parameters.Add("@id", SqlDbType.Int);

command.Parameters.Add("@str", SqlDbType.VarChar, 50);

command.Parameters[0].Value = 1;

command.Parameters[1].Value = "abc";

command.Prepare();

command.ExecuteNonQuery();

command.Parameters[0].Value = 2;

command.Parameters[1].Value = "abcd";

command.ExecuteNonQuery();

Here query preparation is deferred to execution time and we gain all the advantages of parameterization including the fact that we don’t have to send the sql query text over the network everytime. For ODBC the SQL_SOPT_SS_DEFER_PREPARE attribute (for OLEBD it is SSPROP_DEFERPREPARE) determines whether the statement is prepared immediately or deferred until execution. BOL has more information.

It is important to note that when specifying query parameters all statements in the batch should be parameterized. Consider the example where we will use sp_executesql and parameterize the queries:

declare @param_value int, @sqlstring nvarchar(500),

@param_definition nvarchar(500), @col2 int;

set @param_value = 5;

set @sqlstring = N'select @col2_out = col2 from t1 where col1 = @param; update t1 set col1 = col1 + 1 where col2 = 6';

set @param_definition = N'@param int, @col2_out int output';

exec sp_executesql @sqlstring, @param_definition, @param = @param_value, @col2_out = @col2 output;

set @sqlstring = N'select @col2_out = col2 from t1 where col1 = @param; update t1 set col1 = col1 + 1 where col2 = 7';

exec sp_executesql @sqlstring, @param_definition, @param = @param_value, @col2_out = @col2 output;

(@param int, @col2_out int output)select @col2_out = col2 from t1 where col1 = @param; update t1 set col1 = col1 + 1 where col2 = 7

(@param int, @col2_out int output)select @col2_out = col2 from t1 where col1 = @param; update t1 set col1 = col1 + 1 where col2 = 6

declare @param_value int, @sqlstring nvarchar(500),

@param_definition nvarchar(500), @col2 int;

set @sqlstring = N'select @col2_out = col2 from t1 where col1 = @param1; update t1 set col1 = col1 + 1 where col2 = @param2';

set @param_definition = N'@param1 int, @param2 int, @col2_out int output';

set @param_value = 5;

exec sp_executesql @sqlstring, @param_definition, @param1 = @param_value, @param2 = @param_value, @col2_out = @col2 output;

set @param_value = 6;

exec sp_executesql @sqlstring, @param_definition, @param1 = @param_value, @param2 = @param_value, @col2_out = @col2 output;

The compiled plan generated for both executions as:

(@param1 int, @param2 int, @col2_out int output)select @col2_out = col2 from t1 where col1 = @param1; update t1 set col1 = col1 + 1 where col2 = @param2

This is the recommended approach to parameterizing batches with more than one query since it benefits from plan re-use and avoids plan cache bloating problems.

A word of caution on potential over use of prepared queries: If a query is going to be executed only once, then it is probably more efficient to directly execute the query on the server. This avoids the extra network round trip to prepare the query.

6.2 Use Fully Qualified Names

It is advisable to use fully qualified names in queries. There are some significant performance gains in doing so because it avoids the need to look up the default schema for the current user. It also provides us with a plan that can be executed by multiple users (irrespective of the default schemas). Let us demonstrate with an example: table t1 is part of user u1’s default schema s1. Executing a select query as user u1, without a fully qualified object name, results in the cache key user_id to be equal to the schema id to which this table belongs.

select * from t1

Use the query below to view the cache key attributes for the compiled plan for the query above:

select st.text, cp.plan_handle, cp.cacheobjtype, cp.objtype, pa.attribute, pa.value, pa.is_cache_key

from sys.dm_exec_cached_plans cp cross apply sys.dm_exec_sql_text(plan_handle) st

outer apply sys.dm_exec_plan_attributes(cp.plan_handle) pa

where cp.cacheobjtype = 'Compiled Plan'

and st.text not like '%select st.text%'

and pa.is_cache_key = 1

order by pa.attribute;

Text

Plan_

handle

Cache

objtype

Obj

type

Attribute

Value

Is_

cache_

key

select * from t1

0x0600010

0F299431E

B8614C040

000000000

00000

Compiled Plan

Adhoc

user_id

However executing a select query with a fully qualified table name results in a plan who’s cache key user_id is -2 indicating that this plan can be shared across multiple users (irrespective of what their default schema is).

select * from s1.t1

Use the query above to view the user_id cache key attribute for the compiled plan:

Text

Plan_

handle

Cache

objtype

Obj

type

Attribute

Value

Is_

cache_

key

select * from

master.

u1.t1

0x060001

00609A91

2EB86175

04000000

00000000

0000000000

Compiled Plan

Adhoc

user_id

-2

6.3 Use RPC Events over Language Events

RPC execution gives better performance than using language events. For example consider stored procedure executions with different parameters passed to the stored procedures on each execution. If we executed adhoc queries as below:

exec master.dbo.test_proc 1, 1000;

exec master.dbo.test_proc 99, 99000;

exec master.dbo.test_proc 100, 100000;

Then depending on the number of stored procedure executions we may cache the batch. Now if subsequent executions of the stored procedure have different parameter values, then this means we will land up caching all of these unique batches that have small probability of re-execution. This can cause the cache to bloat quickly and come under memory pressure. This situation can be entirely avoided by replacing these adhoc queries with RPC executions of the stored procedures as below:

{call master.dbo.test_proc (1, 1000)}

{call master.dbo.test_proc (99, 99000)}

{call master.dbo.test_proc (100, 100000)}

Now we have eliminated the problem of additional caching of the adhoc batches and have also got performance gains from using RPC.

6.4 Choose Suitable Object Names

It is also important to name tables, functions and procedures suitably. Procedures prefixed with “sp_”, functions names starting with “Fn_”, tables prefixed with “sys” might result in resource database look ups in the absence of fully qualified names in queries using these objects.

6.5 Exact Match of High Re-use Adhoc Query Text

For adhoc queries, the query text needs to be identical. Small differences like extra white space characters or case difference of the query text will result in different plans, and no re-use of cached plans. Comments are also considered part of the query text. Therefore the queries below result in 2 different cached plans:

---this is an example of an adhoc query

if exists(select col1 from t1 where col2 > 5) declare @x int;

---this is an example of an adhoc query with different comment

if exists(select col1 from t1 where col2 > 5) declare @x int;

Use the query below to view the sql_handle and plan_handles for both plans and notice that the sql_handles are different:

select text, sql_handle, plan_handle

from sys.dm_exec_query_stats qs cross apply sys.dm_exec_sql_text(sql_handle)

where text not like '%select text%'

Text

Sql_handle

Plan_handle

---this is an example of an adhoc query with different comment if exists(select col1 from t1 where col2 > 5) declare @x int;

0x0200000

0EC59E433

8B492CC1D

F65C99E5D

352A4E641

06FA0

0x060001

00EC59E43

3B8417204

000000000

000000

---this is an example of an adhoc query if exists(select col1 from t1 where col2 > 5) declare @x int;

0x0200000

04C1C833A

B811F38FB

C18913249

C73C4DFD2

A74DC

0x0600010

04C1C833A

B80167040

000000000

00000

As demonstrated previously different drivers have different default settings for set options. Difference in set options will not result in plan re-use for identical queries. For example, OSQL sets quoted_identifier on while SQL Server Management Studio sets quoted_identifier off. Identical queries issued from these different clients will result in two different plans.

5.0 Retrieving Query Plans from Plan Cache DMV’s

sangeethashekar — Fri, 12 Jan 2007 10:00:00 GMT

The compiled plan is generated for the entire batch (batch level) while individual statements in the batch have query plans (statement level) associated with them. We demonstrated earlier how to retrieve the compiled plan, and in this section we will examine to retrieve the query plans from the plan cache DMV’s sys.dm_exec_query_plan and sys.dm_exec_text_query_plan.

5.1 Query Plans for Safe Auto-Parameterized Queries

Sys.dm_exec_query_plan takes the plan_handle of the cached or currently executing batch and returns among other columns the query plan in XML format. There are some important things to note regarding the query_plan returned from this DMF: First, if the plan_handle is for a query that has been parameterized by the server using either simple or forced parameterization, then the query_plan will just contain the statement text of the un-parameterized (shell) query. In order to retrieve the actual query_plan associated with the parameterized query, the plan handle of the parameterized query should be passed to sys.dm_exec_query_plan. To illustrate this with an example consider the query below that gets auto parameterized:

select col2 from t1 where col1 = 5

Now look at the query plans in sys.dm_exec_query_plan using the query below:

select st.text, qp.query_plan, cp.cacheobjtype, cp.objtype, cp.plan_handle

from sys.dm_exec_cached_plans cp

cross apply sys.dm_exec_sql_text(cp.plan_handle) st

cross apply sys.dm_exec_query_plan(cp.plan_handle) qp

The showplan XML for the shell query with objtype ‘adhoc’ just contains the statement text, while the showplan XML for the parameterized query with objtype ‘prepared’ contains the actual query plan.

Text

Query_plan

Cache

obj

type

obj

type

Plan_handle

select col2 from t1 where col1 = 5

<ShowPlanXML xmlns=

"http://schemas.

microsoft.com/

sqlserver/2004/07/

showplan" Version="1.0" Build="9.00.0000.00">

<StmtSimple

StatementText="


select col2 from

t1 where col1 = 5
"

StatementId="1"

StatementCompId="1"

StatementType="SELECT" />

</Statements></Batch>

</BatchSequence>

</ShowPlanXML>

Compi

led

Plan

Adhoc

0x06000100

7E400B2FB8

4136040000

0000000000

(@1 tinyint)SELECT [col2] FROM [t1] WHERE [col1]=@1

<ShowPlanXML xmlns=

"http://schemas.

microsoft.com/

sqlserver/2004/07/

showplan" Version="1.0" Build="9.00.0000.00">

<StmtSimple

StatementText=

"(@1 tinyint)

SELECT [col2] FROM [t1]

WHERE [col1]=@1"

StatementId="1"

StatementCompId="1"

StatementType="SELECT" StatementSubTreeCost

="0.0032831"

StatementEstRows="1"

StatementOptmLevel=

"TRIVIAL">

<QueryPlan

CachedPlanSize="9"

CompileTime="11" CompileCPU="11"

CompileMemory="64">

<RelOp NodeId="0"

PhysicalOp=

"Clustered Index Seek"

</QueryPlan>

</StmtSimple>

</Statements>

</Batch>

</BatchSequence>

</ShowPlanXML>

Compi

led

Plan

Prep

ared

0x06000100

9F36A508B8

0119040000

0000000000

However if we had executed the query below, then we would have just gotten back one row corresponding to the parameterized query since sys.dm_exec_query_stats only gives query statistics for the parameterized query:

select st.text, qp.query_plan, qs.plan_handle

from sys.dm_exec_query_stats qs

cross apply sys.dm_exec_sql_text(qs.sql_handle) st

cross apply sys.dm_exec_query_plan(qs.plan_handle) qp

5.2 Query Plans for Unsafe Auto-Parameterized Queries

Consider the example below when the query gets unsafe auto-parameterized:

select value_in_use from sys.configurations where configuration_id = 16384

An increment in the SQL Server:SQL Statistics\Unsafe Auto-Params/sec performance counter indicates that the query was unsafe auto-parameterized. The query is parameterized and the shell query is cached. The parameterized query is not cached and is not visible through any of the plan cache DMV’s. The shell query however points to the parameterized query and this is the only way to get to the parameterized query. Now let us look at the query plan in the DMVs:

select st.text, qp.query_plan, qs.plan_handle

from sys.dm_exec_query_stats qs

cross apply sys.dm_exec_sql_text(qs.sql_handle) st

cross apply sys.dm_exec_query_plan(qs.plan_handle) qp

Text

Query_plan

Plan_handle

select value_in_use

from sys.configurations where configuration_id = 16384

<ShowPlanXML xmlns="http://schemas.microsoft.com

/sqlserver/2004/07/showplan" Version="1.0" Build="9.00.0000.00">

<Batch>

</Statements>

</Batch>

</BatchSequence>

</ShowPlanXML>

0x0600010

0CC96AD05

B861D0030

000000000

00000

The query plan returned is corresponding to that of the shell query. Since the query parameterization was unsafe, the parameterized query plan is not cached (shell query just points to it) and is not viewable through the DMVs.

5.3 Query Plans for Multi-Statement Batch

Consider the example below where a batch has more than one query, where some are parameterized:

select * from t1

select col2 from t1 where col1 = 5

Now query the DMVs using the query below:

select st.text, qp.query_plan, cp.cacheobjtype, cp.objtype, cp.plan_handle

from sys.dm_exec_cached_plans cp

cross apply sys.dm_exec_sql_text(cp.plan_handle) st

cross apply sys.dm_exec_query_plan(cp.plan_handle) qp

Text

Query_plan

Cache

objtype

obj

type

Plan_handle

select * from t1 select col2 from t1 where col1 = 5

<ShowPlanXML xmlns="http://

schemas.microsoft.com/

sqlserver/2004/07/showplan"

Version="1.0"

Build="9.00.0000.00">

<Statements><StmtSimple StatementText=

"select * from t1" StatementId="1"

StatementCompId="1"

<QueryPlan

CachedPlanSize="8"

CompileTime="0"

CompileCPU="0"

CompileMemory="56">

<RelOp NodeId="0"

PhysicalOp=

"Clustered Index Scan"

<StmtSimple

StatementText=

"
select col2

from t1 where

col1 = 5
"

StatementId="2"

StatementCompId="2" StatementType

="SELECT" />

</Statements>

</Batch>

</BatchSequence>

</ShowPlanXML>

Compi

led

Plan

Adhoc

0x06000100

9632E81EB8

E134040000

0000000000

(@1 tinyint)SELECT [col2] FROM [t1] WHERE [col1]=@1

<ShowPlanXML xmlns="http://

schemas.microsoft.com/

sqlserver/2004/07/showplan"

Version="1.0"

Build="9.00.0000.00">

<Statements><StmtSimple StatementText="

(@1 tinyint)SELECT [col2]

FROM [t1] WHERE [col1]=@1" StatementId="1"

StatementCompId="2"

</Statements>

</Batch>

</BatchSequence>

</ShowPlanXML>

Compi

led

Plan

Prep

ared

0x0600010

09F36A508

B8E10F040

000000000

00000

There are 2 query plans, one corresponding to the batch and one for the parameterized query. The query plan for the batch has only the shell query statement text for the 2^nd statement and not the parameterized query.

However the same batch executed with showplan_xml on returns a different query plan. Query plan returned has both the parameterized query as well as the shell query statement text.

set showplan_xml on

select * from t1

select col2 from t1 where col1 = 5

Microsoft SQL Server 2005 XML Showplan

<ShowPlanXML xmlns="http://schemas.microsoft.com/

sqlserver/2004/07/showplan"

Version="1.0"

Build="9.00.0000.00">

<Batch>

<StmtSimple StatementText=

"select * from t1"

StatementId="1" StatementCompId="1".

<StmtSimple

StatementText="
select col2

from t1 where col1 = 5
"

StatementId="2"

ScalarOperator

ScalarString="CONVERT_IMPLICIT(int,[@1],0)">

</ShowPlanXML>

There are two things to be called out regarding sys.dm_exec_query_plan:

1. It is actually possible to get back NULL for the query_plan from sys.dm_exec_query_plan. Once scenario under which this can occur is which the plan handle is captured first, and then later passed as a parameter to sys.dm_exec_query_plan. In the time window between when the plan handle is captured and passed to the DMF, the plan may be booted out of the cache due to memory pressure. In such a case, we would get NULL for the query_plan.

2. For queries that are not cached it is not possible to retrieve their query plan using sys.dm_exec_query_plan. The only possibility of capturing the query plans for such queries would be if we queried sys.dm_exec_query_plan while the non-cacheable query was still executing on the server.

5.4 When and How to Use Sys.dm_exec_text_query_plan

The query_plan column returned by sys.dm_exec_query_plan has type XML and suffers from the inherent limitation of the data type that it cannot have nest levels greater than or equal to 128. In SQL Server 2005 RTM and SP1, if the query_plan had a depth of greater than or equal to 128 levels this would prevent the query from returning. The second limitation is that it is not easy to get the query plan of a particular statement in the batch directly from the DMVs without parsing the query plan XML returned from sys.dm_exec_query_plan as demonstrated here.

To address both these limitations, in SQL Server 2005 SP2, we introduced sys.dm_exec_text_query_plan. Sys.dm_exec_text_query_plan is a TVF that takes 3 parameters: plan_handle, statement_start_offset and statement_end_offset. It returns the showplan in text format for the batch or for a specific statement within the batch. Like sys.dm_exec_query_plan, the plan_handle specified can be that of a currently executing or a cached plan.

To summarize, the key differences between sys.dm_exec_query_plan and sys.dm_exec_text_query_plan are as follows: query plan is returned in text format instead of XML in sys.dm_exec_text_query_plan, the output of the query plan is not limited in size, and individual statements in a batch can be specified. The fact that we can extract the query plan for an individual statement in a batch makes this DMV extremely powerful when investigating performance problems on the server.

Consider the example below:

create procedure p1 as

begin

select * from t1

select col2 from t1 where col1 = 5

end

exec p1

When the procedure is executed, a compiled plan for procedure is cached. However it is possible to retrieve the query plans for each statement inside the stored procedure using the query below. This query especially useful when there are long running stored procedures with multiple queries, and we want to identify the queries with poor plans:

select substring(st.text, (qs.statement_start_offset/2) + 1,

((case statement_end_offset

when -1

then datalength(st.text)

else

qs.statement_end_offset

end

- qs.statement_start_offset)/2) + 1) as statement_text

, plan_handle, query_plan

from sys.dm_exec_query_stats qs

cross apply sys.dm_exec_sql_text(qs.sql_handle) st

cross apply sys.dm_exec_text_query_plan(qs.plan_handle, qs.statement_start_offset, qs.statement_end_offset)

Statement_

Text

Plan_handle

Query_plan

select col1 from t1

0x05000100

39D82449B8

610F040000

0000000000

<ShowPlanXML xmlns="http://

schemas.microsoft.com/sqlserver

/2004/07/showplan" Version="1.0"

Build="9.00.0000.00">

<StmtSimple

StatementText="


create proc p1 as


begin
	

select col1 from t1
"

StatementId="1"

</BatchSequence></ShowPlanXML>

select col2 from t1 where col1 = 50000

0x05000100

39D82449B8

610F040000

0000000000

<ShowPlanXML xmlns="http://

schemas.microsoft.com/

sqlserver/2004/07/showplan"

Version="1.0"

Build="9.00.0000.00">

<StmtSimple

StatementText="


create proc p1 as 


begin
	select col1

from t1
	select

col2 from t1 where col1 =

50000" StatementId="1"

</BatchSequence></ShowPlanXML>

The important thing to note here is that using the plan_handle we can retrieve the compiled plan for the entire batch and the sql text of the entire batch. However since query plans are at the statement level, using the statement offsets exposed through sys.dm_exec_query_stats we can retrieve the statement text and its corresponding query plan via sys.dm_exec_text_query_plan. This is especially useful when trying to identify queries in a long batch that may have poor plans, and hence poor performance. Use the query below to identify the top five queries by average CPU time and their query plans:

select top 5 total_worker_time/execution_count as avg_cpu_time,

substring(st.text, (qs.statement_start_offset/2) + 1,

((case statement_end_offset

when -1

then datalength(st.text)

else

qs.statement_end_offset

end

- qs.statement_start_offset)/2) + 1) as statement_text

, plan_handle, query_plan

from sys.dm_exec_query_stats qs

cross apply sys.dm_exec_sql_text(qs.sql_handle) st

cross apply sys.dm_exec_text_query_plan(qs.plan_handle, qs.statement_start_offset, qs.statement_end_offset)

order by total_worker_time/execution_count desc;

4.0 Query Parameterization

sangeethashekar — Thu, 11 Jan 2007 10:00:00 GMT

Using parameters or parameter markers in queries increases the ability of SQL Server to reuse compiled plans. There are two places where parameterization of queries can be done: on the client side application (or mid tier) or on the server side.

4.1 Client Side Parameterization

Client side parameterization (via ADO.NET, ODBC, or sp_executesql) is the recommended approach for query parameterization. Based on the degree of re-execution of queries (once versus multiple executions), client applications can decide to parameterize queries by specifying parameter holders, their data types and lengths in the queries. Therefore between query executions the only thing that changes is the actual value of parameters. This allows for re-use of one parameterized compiled plan. The server will not attempt to parameterize these queries further. It is important to parameterize queries completely and correctly in the client code in order to get the full benefits of parameterized queries. Consider the example below where the client submits a parameterized query using sp_executesql:

declare @param_value int, @sqlstring nvarchar(500),

@param_definition nvarchar(500), @col2 int;

set @sqlstring = N'select @col2_out = t1.col2 from t1 join t2 on t1.col1 = t2.col1 where t2.col2 = @param';

set @param_definition = N'@param int, @col2_out int output';

set @param_value = 5;

exec sp_executesql @sqlstring, @param_definition, @param = @param_value, @col2_out = @col2 output;

set @param_value = 10;

exec sp_executesql @sqlstring, @param_definition, @param = @param_value, @col2_out = @col2 output;

The adhoc query in this case is fully parameterized, and for different values of the parameter the same compiled plan is re-used which gives significant performance gains. The compiled plan is as below:

Text

Plan_handle

Cacheobjtype

Objtype

(@param int, @col2_out int output)select @col2_out = t1.col2 from t1 join t2 on t1.col1 = t2.col1 where t2.col2 = @param

0x06000100

6639AD2BB8

4181040000

0000000000

Compiled Plan

Prepared

The next section describes the best practices for query parameterization and highlights how several common omissions in client side parameterization can manifest as performance degradations.

4.2 Server Side Parameterization: Simple Parameterization

If the query submitted for execution has no parameters specified, then SQL server attempts to parameterize this query. This process is called simple or auto parameterization. The parameterization of queries is done on the server side and is on by default. As the name simple parameterization suggests, only a relatively small set of queries do get parameterized using simple parameterization. Consider the following example:

select col2 from t1 where col1 > 5

select col2 from t1 where col1 > 6

The 2 queries only differ in the literal values in the where clause. When the first query is submitted for execution, SQL Server parameterizes the first and the entries in the cache look like:

Text

Plan_handle

Cacheobjtype

Objtype

select col2 from t1 where col1 > 5

0x06000100

87711124B8

614C040000

0000000000

Compiled Plan

Adhoc

(@1 tinyint)SELECT [col2] FROM [t1] WHERE [col1]>@1

0x06000100

533AC103B8

81CF030000

0000000000

Compiled Plan

Prepared

The second row contains what we call a parameterized query and has objtype of prepared. The parameterized (or prepared) query is the actual compiled plan for the query with the literal values replaced with parameters. The first row contains what we call the shell query and has objtype adhoc. As the name suggests, this entry just saves the exact adhoc batch text in cache and points to the parameterized query plan (the prepared compiled plan). In other words the shell query has a dummy compiled plan which just points to the parameterized compiled plan. The shell query is relatively small in size compared to the parameterized (or prepared query).

There are benefits in caching the shell query: If the same query were to be re-executed, then we would compute the hash value of the sql text of the query and find an exact match in the cache i.e. the shell query. Since this shell query points to the compiled plan, the compiled plan is executed and we are done. If we had not cached this shell query and if the same query was re-executed then the steps followed would be slightly different: first we would compute the hash of the sql text of the query and not find an exact match in the cache. Next, the query is auto-parameterized. Now for this auto-parameterized query we will search the cache and find an exact match in the cache avoiding the need to go to the query optimizer. Finally we execute this compiled plan and are done. Clearly there are performance gains from caching the shell query, especially for applications that re-execute the same query with the same literal values as well. Note that we do not cache insert shell queries because the probability of re-using the exact same adhoc query is low.

SQL Server attempts to auto-parameterize queries and sends the auto-parameterized query to the query processor. Now the query processor decides if it can generate a potentially better plan given the constant values instead of the auto-parameterized query. If the query processor cannot find a better plan with the constant value plugged in, it means that the parameterized plan can be used across different parameter values. This parameterization is considered ‘safe’. In this case we cache both the parameterized and the shell query. However if the query processor can generate a better plan with the literal values, then this parameterization is considered ‘unsafe’. The query is parameterized and the shell query is cached. The parameterized query is not cached and is not visible through any of the plan cache DMV’s. The shell query points to the parameterized query and this is the only way to get to the parameterized query. In other words, unless the exact same query (and parameter value) is re-executed there is no chance of re-using this ‘unsafe’ parameterized query. Queries that already have explicitly defined parameters are not auto-parameterized.

It is important to note that SQL Server will not even attempt to auto-parameterize certain types of queries. A non-exhaustive list of such queries with certain constructs is as below:

1. BULK INSERT

2. IN Expressions (Ex. IN (1, 2, 3))

3. UPDATE with SET clause that has variables

4. SELECT with UNION

5. SELECT with INTO

6. SELECT/UPDATE with FOR BROWSE

7. SELECT/UPDATE/DELETE with OPTION <query hints>

8. SELECT with DISTINCT

9. SELECT/UPDATE/DELETE/INSERT with TOP

10. WAITFOR statements

11. SELECT with GROUP BY, HAVING, COMPUTE

12. DELETE/UPDATE with FROM CLAUSE

13. full text predicates

14. Sub queries

15. FROM Clause of a SELECT statement has table valued method or full text table or OPENROWSET or OPENXML or OPENQUERY or OPENDATASOURCE

16. Comparison predicate of the form EXPR <> a non null constant

17. Queries with JOINS

A general rule of thumb would be that the server auto-parameterizes a query when only one feasible plan for that query is possible. It follows that when auto-parameterization is done, no cost based query optimization is performed by the query optimizer.

4.3 Server Side Parameterization: Forced Parameterization

Clearly since simple parameterization encompasses a small subset of query types, a more powerful option called forced parameterization is available in SQL Server 2005. There are two levels of granularity with which forced parameterization can be enabled: for the entire database or at the query level.

Between the 2 options of database and query level granularity, query level parameterization is the recommended approach. With this alternative, the benefits of parameterization are retained for specific queries and any potential performance problems that may emerge from applying it at the database level are eliminated. Forced parameterization at the query level can be specified using plan guides. Consider the example below:

select t1.col2, t2.col2 from t1 join t2 on t1.col1 = t2.col1 and t1.col2 > 5

This query does not get parameterized when the database parameterized option is set to simple. Now let us create a plan guide for queries of this template that differ only in the where clause parameter value:

declare @stmt nvarchar(max), @params nvarchar(max);

exec sp_get_query_template N'select t1.col2, t2.col2 from t1 join t2 on t1.col1 = t2.col1 and t1.col2 > 5', @stmt output, @params output

exec sp_create_plan_guide N'JoinGuide', @stmt, N'Template', NULL, @params, N'OPTION(PARAMETERIZATION FORCED)'

select t1.col2, t2.col2 from t1 join t2 on t1.col1 = t2.col1 and t1.col2 > 15

Now if we look at the cached plans we have the parameterized and the shell queries cached.

Text

Plan_handle

Cacheobjtype

Objtype

select t1.col2, t2.col2 from t1 join t2 on t1.col1 = t2.col1 and t1.col2 > 15

0x060001009

DE67C01B8C1

B0040000000

00000000000

000000

Compiled Plan

Adhoc

(@0 int)select t1 . col2 , t2 . col2 from t1 join t2 on t1 . col1 = t2 . col1 and t1 . col2 > @0

0x060001009

647E335B881

70040000000

00000000000

000000

Compiled Plan

Prepared

BOL has more information on plan guides.

Next let us consider the database level option. Forced parameterization at the database level can be enabled using the alter database DDL:

alter database <database_name> set parameterization forced

For some databases with a high volume of queries it may significantly reduce the frequency of query compilations. In general, a broad class of DML queries are parameterized and literal values are replaced with parameters during query compilation. BOL article ‘Forced Parameterization’ has a list of query clauses and in literals in query constructs that will not be forced parameterized.

There are some factors to consider before turning on forced parameterization for a database. Examine these factors carefully along with query level forced parameterization options before turning on forced parameterization at the database level. Turning on (or off) forced parameterization flushes the plan cache of all entries, except those that were then compiling or executing. Plans that were then compiling or executing are parameterized the next time the query is executed. The database parameterization setting is preserved when re-attaching or restoring a database. Distributed queries may also be parameterized as long these queries are executing in a database where forced parameterization is enabled. Since parameterization replaces the literal values in the query with parameters, the query optimizer may very well choose a sub optimal plan. Specifically, the query optimizer is less likely to match the query to an index, indexed view or a computed column. It is also less likely to choose optimal plans for partitioned tables and distributed partitioned views. Thus forced parameterization can have some serious performance ramifications and should be used with caution.

Note that it is possible to turn on forced parameterization at the database level and then use plan guides to specify simple parameterization for specific queries that suffer from poor performance due to forced parameterization. However the reverse approach i.e. specifying forced parameterization for specific queries, with the database parameterization option simple is what is recommended.

Using forced parameterization the performance problems associated with not re-using cached plans seems to have to been solved largely. However in some cases it can give rise to another set of problems emerging from parameter sniffing. Parameter sniffing can be explained as follows: If the parameter values are specified during the first execution of a query then the query optimizer attempts to pick the best plan based on the current parameter values provided. Parameter values are sniffed for stored procedure executions, queries submitted for sp_executesql, and prepared queries. While in most cases this works well, in some cases where the optimal plan for a query varies greatly with the range of parameter values, there can be some performance degradation. This is especially true if the first set of parameter values are atypical, because it causes a sub-optimal plan (for other parameter values) to be inserted into cache and re-used as well. Consider the following example: Sales table has three columns: transaction id, country id, and total_amount. We also know that majority of the sales occur in country with id = 1, and country with id = 2 has far fewer rows in the sales table. If we had a stored procedure that reported sales by country id as below:

create proc sales_report @country_id int

as begin

select * from sales where country_id = @country_id

end

If we now executed the stored proc with country id 2 first, then the query_plan can be obtained by:

select text, query_plan, cacheobjtype, objtype

from sys.dm_exec_cached_plans cp cross apply sys.dm_exec_sql_text(plan_handle)

outer apply sys.dm_exec_query_plan(plan_handle)

where cacheobjtype = 'Compiled Plan' and objtype = 'Proc'

and text not like '%select text%'

The query plan shows that the query optimizer does an index seek when we execute the procedure with country id 2 first, where as the query optimizer does a clustered index scan with country id 1 on first execution of the stored procedure. This difference in plan for the stored procedure execution comes from parameter sniffing and cause poor query execution time for more frequently executed parameter values if the first parameter was not a representative value. Or if the parameterized plan removed from cache due a cache flush and the next stored procedure execution was with atypical value. In such cases one way to bypass parameter sniffing would be to modify the stored procedure as follows using local variables:

create proc sales_report @country_id int, @country_id_default int = 1

as begin

set @country_id_default = @country_id;

select * from sales where country_id = @country_id_default;

end

Now irrespective of what order the parameters are supplied, the query optimizer does a clustered index scan. This is because the optimizer sniffs the @country_id_default variable which is always set to the more commonly used value (in this case 1), leading to the same plan irrespective of what parameter we pass to the procedure. Notice that the parameter we pass to the stored procedure is not part of the select statement where clause. Also note that the set statement cannot affect the compiled plan chosen by the query optimizer because it is evaluated only at execution time. There are other options like creating the procedure with the ‘with recompile’ option. More details are available in this white paper and in this blog post.

3.0 How Cache Lookups Work

sangeethashekar — Wed, 10 Jan 2007 10:00:00 GMT

Each cache store is implemented as a hash table. A hash value and cache key pair is used in order to check if the compiled plan is cached for a given query in the cache stores. The hash value of all cache objects is computed as (database_id * object_id) mod (hash table size), and this specifies the hash bucket. Note that the object_id for entries in the SQLCP cache store is the hash of the entire batch text. All attributes of a cached plan that must match in order for the look up to succeed is termed as a cache key. A cache key is used to find an exact match for a plan in that hash bucket. More information regarding cache keys can be found in BOL article on sys.dm_exec_plan_attributes.

3.1 Cache Look Up Mechanisms

There are two types of look ups for the top level cache objects: ID and text look up. For objects like procedures, functions, triggers, the ID look up is used. The ID look up first determines the kind of cache object (and cache store) we are trying to look up based on the object type. For procedures, functions, triggers we will look up a compiled plan in the OBJCP cache store. Next the cache key consisting of database id, object id, proc number, object type, context etc is used to look up the plan.

When a procedure, function or trigger is submitted for execution, the following steps are executed:

1. We do an ID look up to find the compiled plan in the cache.

a. If we find a compiled plan then we can proceed to step 2.

b. If not, then we do a name to ID resolution from the metadata cache. Once the latest IDs are obtained, then we attempt another cache look up. If that too fails, then we know the query needs to be compiled. Before compilation, we grab an exclusive lock and attempt a final cache lookup just to be sure that a compiled plan has not been inserted while we were waiting to acquire the compile lock. If this too fails, we do a full compile, insert a new compiled plan and release the compile lock.

2. Check to see if the compiled plan has any free MXCs in its lookup list.

a. If yes, then we remove it from the lookup list and use it.

b. If no, then we create one.

3. After query execution, we either return the MXC to the lookup list (if it must be cached) or destroy it.

For ID look ups we must make sure that there is only one match for a given ID. A compile lock is taken so that only one compilation can take place at a time. The other threads will be blocked waiting to acquire the compile lock. Therefore it is not possible to have duplicate plans for procedures, functions, triggers, etc. Xprocs however are an exception. Since Xproc entries consume very little memory, we avoid the need to grab an exclusive lock in this case by allowing duplicate entries for the same IDs. The look up logic is implemented such that the latest Xproc entry for an ID is returned, and the rest are aged out with time.

The text look up is used for adhoc and prepared sql batches. All dynamic sql look ups are from the SQLCP cache store and the cache key consists of the batch text, dbid (id of the database where the query was executed), set options among other things. When an adhoc query or a prepared sql batch is submitted for execution, the following steps are executed:

Sql text look up in the SQLMGR cache to see if we have the batch text already cached.
1. If yes, we use this to lookup the compiled plan in the cache stores (using the CP cache store key). The compiled plan has a reference to the entry in the SQLMGR cache.
2. If no, then this implies there is no compiled plan for this batch in the plan cache stores, and one has to be generated.

Either way at the end of step 1 we have the compiled plan for the batch.

Check to see if the compiled plan has any free MXCs in its lookup list.
1. If yes, then we remove it from the lookup list and use it.
2. If no, then we create one.
After query execution, we either return the MXC to the lookup list (if it must be cached) or destroy it.

Notice that during the lookup in the SQLMGR cache, we don’t hold any compile locks. Therefore it is possible to have duplicate entries in the plan cache for simultaneous compiles. Subsequent looks ups will however only return the last plan inserted, leaving other duplicate plans to just age out.

3.2 Cache Keys

The cache keys for a plan are exposed through sys.dm_exec_plan_attributes. Attributes that have is_cache_key set to 1 are cache keys for that particular plan. More information regarding sys.dm_exec_plan_attributes is available in BOL.

Consider the example query below: the query is executed once from Sql Server Management studio and using OSQL:

---this is an example for how to use sys.dm_exec_plan_attributes

if exists(select col1 from t1 where col2 > 5) declare @x int;

Use the query below to view the cached compiled plans:

select text, plan_handle, cacheobjtype, objtype

from sys.dm_exec_cached_plans cp cross apply sys.dm_exec_sql_text(plan_handle)

where cacheobjtype = 'Compiled Plan'

Text

Plan_handle

Cacheobjtype

Objtype

---this is an example for how to use sys.dm_exec_plan_attributes if exists(select col1 from t1 where col2 > 5) declare @x int;

0x060001009

1D3CF01B861

11040000000

00000000000

000000

Compiled Plan

Adhoc

---this is an example for how to use sys.dm_exec_plan_attributes if exists(select col1 from t1 where col2 > 5) declare @x int;

0x060001009

1D3CF01B881

1B040000000

00000000000

000000

Compiled Plan

Adhoc

The cached compiled plans have the exact same query text but have different plan_handles. To understand why the same query executed using different client drivers ends up generating two different plans instead of re-using the same plan, use the query below:

select st.text, cp.plan_handle, cp.cacheobjtype, cp.objtype, pa.attribute, pa.value, pa.is_cache_key

from sys.dm_exec_cached_plans cp cross apply sys.dm_exec_sql_text(plan_handle) st

outer apply sys.dm_exec_plan_attributes(cp.plan_handle) pa

where cp.cacheobjtype = 'Compiled Plan' and cp.objtype = 'Adhoc'

and st.text not like '%select st.text%' and pa.is_cache_key = 1

order by pa.attribute;

The result set will point out queries with same text, but different cache key values as below:

Text

Plan_

handle

Cache

objtype

Obj

type

Attri

bute

Value

Is_

cache_

key

---this is an

example for how

to use

sys.dm_exec_plan_

attributes

if exists(select

col1 from t1

where col2 > 5)

declare @x int;

0x060001009

1D3CF01B821

AA030000000

00000000000

000000

Compiled Plan

Adhoc

set_

options

4347

---this is an

example for how

to use sys.dm_exec_plan_

attributes

if exists(select

col1 from t1

where col2 > 5)

declare @x int;

0x060001009

1D3CF01B8A1

AB030000000

00000000000

000000

Compiled Plan

Adhoc

set_

options

187

As demonstrated above several connection properties like set options, date format, language can affect plan re-use.

Other subtle things that usually go unnoticed, but prevent plan re-use are differences in white space characters or comments in an adhoc query. Even one character difference amounts to a different plan since the hash value of the sql text is different. Note that the hash value is computed for the entire text even if the batch text is larger than 8K).

For non-dynamically bound temp tables as in the example below we add the connection spid to the cache key in order to reduce the number of re-compiles. In the example below, a select query from connection 1 is issued, followed by the select query from connection 2, followed by a re-issue of the select query from connection 1.

Connection 1

Connection 2

create table #t(a int)

insert into #t values (5)

select * from #t

create table #t(a int)

insert into #t values (2)

select * from #t

The cache has 2 compiled plan entries with the same sql text but different plan_handles:

Text

Plan_handle

Cacheobjtype

Objtype

select * from #t

0x060001006

BB48B2DB841

29040000000

00000000000

000000

Compiled Plan

Adhoc

select * from #t

0x060001006

BB48B2DB8E1

46040000000

00000000000

000000

Compiled Plan

Adhoc

Although cache key attributes exposed through sys.dm_exec_plan_attributes are identical in this case, the two cache entries are tagged with the connection spid. Thus for non-dynamically bound temp tables, connection spid is part of the cache key. Adding the connection spid to the cache key greatly reduces the number of recompiles. If this were not the case, then it would re-compile the second execution of the select query from connection 1.

Accessing inserted and deleted tables inside one CLR trigger needs to be distinguished from queries with the same text inside another CLR trigger. Hence all queries are executed inside a CLR triggers are tagged with two additional cache keys: dbid and objid of the CLR trigger that issued them. Consider the example below: We create two CLR triggers on two tables t1 and t2 with different column meta data as below. Both CLR triggers execute the same test_method() when fired.

create trigger dml_clr_trigger1 on t1 after update

as external name trigger_assembly.test_class.test_method

create trigger dml_clr_trigger2 on t2 after update

as external name trigger_assembly.test_class.test_method

In test_method() we execute the following query:

using SqlConnection connection = new SqlConnection ("context connection = true");

connection.Open();

SqlCommand command = connection.CreateCommand();

command.CommandText = "if exists(select * from inserted) declare @x int";

command.ExecuteNonQuery();

Now if we fire both the triggers, then we should have two plans in the cache whose text is identical, but plan_handle is different.

Text

Plan_handle

Cacheobjtype

Objtype

if exists(select * from inserted) declare @x int

0x06000100

04E1AF07B8

413B040000

0000000000

Compiled Plan

Prepared

if exists(select * from inserted) declare @x int

0x06000100

04E1AF07B8

A128040000

0000000000

Compiled Plan

Prepared

Now there is couple of things to notice regarding the cache key attributes for these two compiled plans: First, the cache key attributes returned above for the two plans are identical. However internally we also have the objectid and the dbid of the CLR triggers as part of the cache key. They are not exposed in SQL Server 2005. Re-using the compiled plan from the inproc query inside dml_clr_trigger1 for the query inside dml_clr_trigger2 is not an option because the inserted tables in the two cases have different columns. Hence we need to cache two plans that have the exact same text, same values for other currently exposed cache keys but need a way to distinguish them. Hence we add dbid and objectid of the CLR trigger to the cache key of the queries inside CLR triggers. The second thing to notice here is the objtype of the inproc query is prepared.

2.0 Sql_Handle and Plan_Handle Explained

sangeethashekar — Tue, 09 Jan 2007 20:18:00 GMT

2.1 What is a Plan_Handle

Cached compiled plans are stored in the SQLCP or the OBJCP cache stores. A cached compiled plan can be retrieved from either of these cache stores using the plan_handle of the compiled plan. The plan_handle is a hash value derived from the compiled plan of the entire batch. It is therefore guaranteed to be unique for every compiled plan and can serve as an identifier for compiled plans. It is important to note a couple of points here:

1. Since the compiled plan is generated for the entire batch, the plan_handle too is an identifier of the compiled plan for the entire batch. Individual statements in the batch have query plans associated with them and the compiled plan can be thought of as a container for all these query plans. When the compiled plan for a batch is removed from the cache, the query plans for the queries/statements in the batch are also deleted. The query plan for individual statements in the batch can be retrieved using the plan_handle and statement offsets as demonstrated later in this section.

2. The plan_handle for a compiled plan remains the same even if one or more statements in the batch get recompiled.

2.2 What is a Sql_Handle

While the compiled plans are stored in the two cache stores described above, the actual sql text of the batch is stored in the SQL Manager Cache (SQLMGR). Like a compiled plan, the sql text is stored per batch, including the comments, in its entirety. The sql text cached in the SQLMGR cache can be retrieved using the sql_handle. The sql_handle contains the MD5 hash of the entire batch text and is guaranteed to be unique for every batch. Therefore the sql_handle serves as an identifier for the batch text in the SQLMGR cache.

There are some distinctive aspects of the SQLMGR cache that sets it apart from other caches:

1. While the SQLMGR cache does contribute to system memory pressure, it is not subject to the common cache store entries eviction algorithms. In other words the SQLMGR cache is not built on the same framework as the other CP cache stores.

2. There is only one global SQLMGR cache but there are as many top level memory objects (to allocate entries in this cache) as there are schedulers on the machine. This results in better data locality.

3. Memory is allocated for the SQLMGR cache from the buffer pool. The query below can be used to find the size of the SQLMGR cache:

select sum(bytes_used) as total_bytes_used

from sys.dm_os_memory_objects where type = 'MEMOBJ_SQLMGR'

go

In SQL Server 2005, there is no mechanism to view the contents of the SQLMGR cache.

2.3 Sql_Handle: Plan_Handle :: 1: N

While the sql_handle for every batch text is unique, the plan_handle need not be unique. This results in a 1:N relation between sql_handles and plan_handles. Such a condition occurs when the cache key for the compiled plans is different. This may occur due to change in set options between two executions of the same batch.

As an example consider the batch below: the only difference between 2 consecutive executions of this batch is the set options i.e. set quoted_identifier is on/off.

set quoted_identifier off

---this is an example for sql_handles, plan_handles interaction

if exists(select col1 from t1 where col2 > 5) declare @x int;

set quoted_identifier on

---this is an example for sql_handles, plan_handles interaction

if exists(select col1 from t1 where col2 > 5) declare @x int;

Use the following query to look to get the sql_handle, plan_handle and the sql text of the batch:

select st.text, qs. sql_handle, qs.plan_handle

from sys.dm_exec_query_stats qs cross apply sys.dm_exec_sql_text(sql_handle) st

There will be 2 entries with the same text and sql_handle, but different plan handles as below:

Text

Sql_handle

Plan_handle

---this is an example for sql_handles, plan_handles interaction if exists(select col1 from t1 where col2 > 5) declare @x int;

0x020000003

46A991F313A

868044F8006

18391CA450F

24C927

0x060001003

46A991FC844

65060000000

00000000000

000000

---this is an example for sql_handles, plan_handles interaction if exists(select col1 from t1 where col2 > 5) declare @x int;

0x020000003

46A991F313A

868044F8006

18391CA450F

24C927

0x060001003

46A991FC8C4

42060000000

00000000000

000000

What this effectively means is that we have two plans corresponding to the same batch, and it under scores the importance of making sure that the plan cache affecting set options are the same when the same queries are executed repeatedly for plan re-use. A common pitfall that most don’t realize is that different clients may have different default values for the set options. For example, OSQL (ODBC Driver) sets quoted_identifier off for every connection, while SQL Server Management Studio (ADO.NET) sets quoted_identifier on. Executing the same queries from these two clients will result in multiple plans (as described in the example above).

We have a strict 1:N relationship of sql_handles and plan_handles. The life time of entries in the SQLMGR cache is tied to the association of the sql_handle to at least one plan_handle. Plans (and therefore plan_handles) may be removed from the CP cache stores either due to memory pressure or because the object associated with the object cached plan is dropped. When the last plan_handle associated with a sql_handle is destroyed, the entry in the SQLMGR cache is also deleted.

2.4 Plan_Handle, Sql_Handle and Plan Cache DMV’s

In the following section we will demonstrate how the sql_handle and plan_handle can be used to retrieve useful information from the plan cache related DMVs and diagnose performance problems.

2.4.1 Sys.dm_exec_cached_plans

The plan_handle can be obtained from sys.dm_exec_cached_plans DMV which has one row per cached query plan. In addition to the plan_handle this DMV has other useful information regarding the cached query plan like:

Number of times the query plan has been used (usecounts)
Number of bytes consumed by this cache object (size_in_bytes)
Type of the cache object i.e. if it’s a compiled plan, or a parse tree or an xproc (cacheobjtype)
Memory address of the cache object (memory_object_address). The memory_object_adress of the cache object can used to get the memory breakdown of the cache object as demonstrated in the previous section.

Note that this DMV does not have the batch text associated with a compiled plan. The batch text can be retrieved by passing the plan_handle retrieved from sys.dm_exec_cached_plans to sys.dm_exec_sql_text as a parameter. The query below gives us the plan_handle, usecounts, size_in_bytes of the compiled plan, cacheobjtype, the compiled plan memory object address and the entire batch text:

select st.text, cp.plan_handle, cp.usecounts, cp.size_in_bytes, cp.cacheobjtype, cp.objtype, cp.memory_object_address

from sys.dm_exec_cached_plans cp

cross apply sys.dm_exec_sql_text(cp.plan_handle) st

order by cp.usecounts desc

If you order the result set by size_in_bytes and observe that the cache has just a few large plans with high usecounts, then this may be due to the following reasons:

a) The batch may contain a large number of statements.

b) The query plan for one of the queries in the multi-statement batch is very large.

c) The compiled plan may have a large number of concurrent users increasing the cacheable execution time memory.

d) The plan may be currently executing and the query plan for the currently executing statement in the batch my require a large amount of memory to execute. This exeuction memory is allocated from the cache stores, and is partially returned to the buffer pool after query execution. Therefore the plan would have a siginificantly larger size during execution than when its not being executed.

Now use the procedure PlanBreakdown and function ComplPlanDetails as described in this posting to get size and composition of the compiled plan memory object. The PlanDetails table contains one row per memory object in each plan. The PlanSummary table gives the mxc_count, xstmt_count, cstmt_count and cursor_count. The checklist below details how to interpret the data in the tables PlanDetails and PlanSummary:

a) If a plan has a small xstmt_count and large aggregate size, then examine the PlanDetails table to see if one XStmt in particular is consuming more memory than the others or if the memory is evenly distributed.

b) An mxc_count of greater than one indicates concurrent use of the plan.

c) The xstmt_count in the total will give some indication on the usage pattern of the plan. If the xstmt_count is low, it indicates many statements being executed concurrently versus a high xstmt_count which indicates one statement being executed by a large number of users.

d) An xstmt_count greater than the cstmt_count indicates concurrent use of some statements within the plan.

e) A large cursor_count may indicate a leaked cursor (opening cursors but failign to close them).

f) If a plan with a large number of CStmts is causing performance degradation, it should be examined to see if they can be split into multiple batches or if they can be rewriten using stored procedures.

2.4.2 Sys.dm_exec_sql_text

Sys.dm_exec_sql_text takes either a sql_handle or a plan_handle as a parameter and returns sql text associated with the cached plan. In other words the parameter to this DMF can be any of the following: sql_handle for adhoc sql, sql_handle for object, sql_handle for an XP, plan_handle for TSQL module (triggers, functions, procedures), or plan_handle to a CLR compiled plan. The DMF resolves the supplied handle appropriately, and if the supplied handle was for a compiled plan or prochdr then sensitive information like passwords are blocked in the returned sql text. The DMF text column supplies the entire batch text for dynamic sql and for modules like triggers, procedures, functions it gives the module definition.

Sys.dm_exec_sql_text is useful in quickly identifying identical batches that may have different compiled plans due to several factors like set options differences (as demonstrated above section).

2.4.3 Sys.dm_exec_cached_plan_dependent_objects

The plan_handle of a compiled plan can also be passed to sys.dm_exec_cached_plan_dependent_objects. This DMF returns a table with one row for every dependant object of the compiled plan i.e. it returns one row for each MXC and cursor. If the supplied plan_handle is not for a compiled plan then the DMF returns NULL. The query below gets the dependant objects for all compiled plans, their usecounts and their memory_object_address:

select st.text, cp.plan_handle, do.usecounts, do.cacheobjtype,

do.memory_object_address

from sys.dm_exec_cached_plans cp

cross apply

sys.dm_exec_sql_text(cp.plan_handle) st

cross apply

sys.dm_exec_cached_plan_dependent_objects(cp.plan_handle) do

Consider the example below where the stored procedure is executed simultaneously from 10 connections:

create procedure p1

begin

declare @x int;

set @x = 0;

while (@x < 10000000)

set @x = @x + 1;

select t1.col2, t2.col2 from t1 join t2 on t1.col1 = t2.col1 here t1.col1 = 50000;

end

Now query sys.dm_exec_cached_plans to retrieve the usecounts, memory_object_address and plan_handle information for the compiled plan:

Text

Plan_handle

Memory_

Object_

Address

Usecounts

create procedure p1 as begin declare @x int; set @x = 0; while (@x < 10000000) set @x = @x + 1; select t1.col2, t2.col2 from t1 join t2 on t1.col1 = t2.col1 where t1.col1 = 50000; end

0x050001003D

299E5FB8A193

070000000000

000000000000

0x0793A0C0

Now pass these plan_handle and memory_object_address to the function CompPlanDetails (described in a previous posting).

select plan_handle, memory_object_address, parent_address, type, name

from dbo.CompPlanDetails

(0x0793A0C0, 0x050001003D299E5FB8A19307000000000000000000000000)

Plan_Handle	Memory_ object_ address	Parent_ address	Type
0x050001003 D299E5FB8A1 93070000000 00000000000 000000	0x0793AD58	0x0793A0C0	MEMOBJ_ XSTMT
0x050001003 D299E5FB8A1 93070000000 00000000000 000000	0x0793A538	0x0793A0C0	MEMOBJ_ COMPILE_ ADHOC
0x050001003 D299E5FB8A1 93070000000 00000000000 000000	0x0793A948	0x0793A0C0	MEMOBJ_ PLAN SKELETON
0x050001003 D299E5FB8A1 93070000000 00000000000 000000	0x0793AB50	0x0793A0C0	MEMOBJ_ STATEMENT
0x050001003 D299E5FB8A1 93070000000 00000000000 000000	0x07BBA040	NULL	MEMOBJ_ QUERY EXECCNTXT FORSE
0x050001003 D299E5FB8A1 93070000000 00000000000 000000	0x06EB0028	NULL	MEMOBJ_ EXECUTE
0x050001003 D299E5FB8A1 93070000000 00000000000 000000	0x06F94028	NULL	MEMOBJ_ EXECUTE
0x050001003 D299E5FB8A1 93070000000 00000000000 000000	0x0627A028	NULL	MEMOBJ_ EXECUTE
0x050001003 D299E5FB8A1 93070000000 00000000000 000000	0x07A9A028	NULL	MEMOBJ_ EXECUTE
0x050001003 D299E5FB8A1 93070000000 00000000000 000000	0x07B66028	NULL	MEMOBJ_ EXECUTE
0x050001003 D299E5FB8A1 93070000000 00000000000 000000	0x0793A0C0	NULL	MEMOBJ_ COMPILE_ ADHOC
0x050001003 D299E5FB8A1 93070000000 00000000000 000000	0x06FB6028	NULL	MEMOBJ_ EXECUTE
0x050001003 D299E5FB8A1 93070000000 00000000000 000000	0x072E2028	NULL	MEMOBJ_ EXECUTE
0x050001003 D299E5FB8A1 93070000000 00000000000 000000	0x07BFA028	NULL	MEMOBJ_ EXECUTE
0x050001003 D299E5FB8A1 93070000000 00000000000 000000	0x07B20028	NULL	MEMOBJ_ EXECUTE
0x050001003 D299E5FB8A1 93070000000 00000000000 000000	0x07464028	NULL	MEMOBJ_ EXECUTE

There are 10 MXC’s corresponding to the simultaneous executions of the stored procedure. Now let us look at the dependant objects DMV for the compiled plan with plan handle 0x050001003D299E5FB8A19307000000000000000000000000:

select st.text, do.usecounts, do.cacheobjtype,

do.memory_object_address

from sys.dm_exec_cached_plans cp

cross apply

sys.dm_exec_sql_text(cp.plan_handle) st

cross apply

sys.dm_exec_cached_plan_dependent_objects(cp.plan_handle) do

where cp.plan_handle = 0x050001003D299E5FB8A19307000000000000000000000000

Text	Usecounts	Cacheobjtype	Memory_ object_ address
create procedure p1 as begin declare @x int; set @x = 0; while (@x < 10000000) set @x = @x + 1; select t1.col2, t2.col2 from t1 join t2 on t1.col1 = t2.col1 where t1.col1 = 50000; end	1	Executable Plan	0x06FB6028
create procedure p1 as begin declare @x int; set @x = 0; while (@x < 10000000) set @x = @x + 1; select t1.col2, t2.col2 from t1 join t2 on t1.col1 = t2.col1 where t1.col1 = 50000; end	1	Executable Plan	0x06EB0028
create procedure p1 as begin declare @x int; set @x = 0; while (@x < 10000000) set @x = @x + 1; select t1.col2, t2.col2 from t1 join t2 on t1.col1 = t2.col1 where t1.col1 = 50000; end	1	Executable Plan	0x06F94028
create procedure p1 as begin declare @x int; set @x = 0; while (@x < 10000000) set @x = @x + 1; select t1.col2, t2.col2 from t1 join t2 on t1.col1 = t2.col1 where t1.col1 = 50000; end	1	Executable Plan	0x072E2028
create procedure p1 as begin declare @x int; set @x = 0; while (@x < 10000000) set @x = @x + 1; select t1.col2, t2.col2 from t1 join t2 on t1.col1 = t2.col1 where t1.col1 = 50000; end	1	Executable Plan	0x0627A028
create procedure p1 as begin declare @x int; set @x = 0; while (@x < 10000000) set @x = @x + 1; select t1.col2, t2.col2 from t1 join t2 on t1.col1 = t2.col1 where t1.col1 = 50000; end	1	Executable Plan	0x07BFA028
create procedure p1 as begin declare @x int; set @x = 0; while (@x < 10000000) set @x = @x + 1; select t1.col2, t2.col2 from t1 join t2 on t1.col1 = t2.col1 where t1.col1 = 50000; end	1	Executable Plan	0x07B20028
create procedure p1 as begin declare @x int; set @x = 0; while (@x < 10000000) set @x = @x + 1; select t1.col2, t2.col2 from t1 join t2 on t1.col1 = t2.col1 where t1.col1 = 50000; end	1	Executable Plan	0x07A9A028
create procedure p1 as begin declare @x int; set @x = 0; while (@x < 10000000) set @x = @x + 1; select t1.col2, t2.col2 from t1 join t2 on t1.col1 = t2.col1 where t1.col1 = 50000; end	1	Executable Plan	0x07464028
create procedure p1 as begin declare @x int; set @x = 0; while (@x < 10000000) set @x = @x + 1; select t1.col2, t2.col2 from t1 join t2 on t1.col1 = t2.col1 where t1.col1 = 50000; end	1	Executable Plan	0x07B66028

Notice that this DMV has the usecounts of the MXC. It also gives the memory_object_address of the MXC. Now upon re-execution of the stored procedure from one connection, the compiled plan has a usecount of 11 while one of the MXC’s is re-used incrementing its usecount to 2.

MXC’s may be deleted under memory pressure and re-created on subsequent execution of the same compiled plan. Therefore the sum of the usecounts of the MXCs as reported in the dependant objects DMV need not always equal the usecounts of the compiled plan. Infact it is strictly less than or equal to the usecounts of the compiled plan.

Note that there is a one to one mapping between the dependant objects listed here and in sys.dm_os_memory_objects based on memory_object_address. As demonstrated in the previous section, sys.dm_os_memory_objects provides information on the memory objects allocated including their memory object address, parent address of the memory object if any, pages allocated, page size etc.

2.4.5 Sys.dm_exec_requests

Sys.dm_exec_requests returns execution and resource consumption information for currently executing requests in the server. This DMV also provides the sql_handle, plan_handle and statement offsets for each query. It can therefore be used to identify the long running queries among the requests currently executing in the server using the query below:

select top 10 substring(st.text, (er.statement_start_offset/2) + 1,

((case statement_end_offset

when -1

then datalength(st.text)

else

er.statement_end_offset

end

- er.statement_start_offset)/2) + 1) as statement_text

, *

from sys.dm_exec_requests er

cross apply sys.dm_exec_sql_text(er.sql_handle) st

order by total_elapsed_time desc

BOL provides information on the columns returned by this DMV. It also lists the relationship cardinalities between sys.dm_exec_requests and the other plan cache related DMVs.

2.4.6 Sys.dm_exec_query_stats

The compiled plan is generated for the entire batch, while query plans are for individual statements in the batch. When a multi-statement batch is executing on the server, in order to identify the slow running queries, we will need to drill down further and look at the query plans for the individual statements in the batch. This is where sys.dm_exec_query_stats is extremely useful. Sys.dm_exec_query_stats returns aggregate performance statistics for cached query plans. This DMV contains a row per query/statement within the cached plan. It is important to note that when the compiled plan is removed from cache, the rows corresponding to query plans for statements in that batch are also deleted from this DMV. The DMV provides both the sql_handle and the plan_handle, so we can join with sys.dm_exec_sql_text and sys.dm_exec_cached_plans to retrieve the batch text and the compiled plan for the batch. It also provides statement offsets, both start and end off sets of the query in the batch. Note that these offsets start at zero and an end offset of -1 indicates end of the batch. The statement offsets can be used in combination with the sql_handle passed to sys.dm_exec_sql_text to extract the query text from the entire batch text as demonstrated below. The query below selects the top 10 queries with highest CPU time and is useful in identifying expensive queries that were executed on the server.

select top 10 substring(st.text, (qs.statement_start_offset/2) + 1,

((case statement_end_offset

when -1

then datalength(st.text)

else

qs.statement_end_offset

end

- qs.statement_start_offset)/2) + 1) as statement_text,

from sys.dm_exec_query_stats qs

cross apply sys.dm_exec_sql_text(qs.sql_handle) st

order by total_elapsed_time/execution_count desc

Sys.dm_exec_query_stats returns a wealth of information regarding the per-statement IO, CPU and duration statistics. BOL has information on columns returned by this DMV and how to interpret the data in each of these columns. Note that the DMV is updated after the query execution is completed, so it might beneficial to query this DMV a couple of times to get updated information if there is a workload currently executing on the server.