Analyzing the SQL Server Plan Cache

By: Atif Shehzad   |   Updated: 2009-01-08   |   Comments (3)   |   Related: > Performance Tuning

Problem

The cache management mechanism plays an important role in performance of any system. Like any reliable DBMS, SQL Server enjoys a sophisticated cache management system for optimized performance without the need for any user intervention. There are ways to add a plan or data to the SQL Server cache or to remove a plan or data from SQL Server cache, but these techniques are only recommended for testing or troubleshooting purposes. Keeping in mind the importance of the cache mechanism, how could one get the plans and their usage statistics in SQL Server?

Solution

In releases prior to SQL Server 7.0, the plan cache was a separately configurable cache area in total memory used by SQL Server. Only stored procedures were cached in that part of cache. For this reason it was named the procedural cache. In SQL Server 7.0 and forwards the plan cache is not a separate area of memory in SQL Server. Now SQL Server uses a very dynamic integrated memory management and cache management mechanism.

The following script may be used on SQL Server 2000 and forward. It will provide contents of the SQL Server plan cache along with usage frequency.

Script # 1: Get SQL Server plan cache contents and their usage for SQL Server 2000 and onwards

USE Master
GO
SELECT 
UseCounts, RefCounts,CacheObjtype, ObjType, DB_NAME(dbid) as DatabaseName, SQL
FROM syscacheobjects
ORDER BY dbid,usecounts DESC,objtype
GO

Following is a partial result set from script #1 for SQL Server 2000.

For SQL Server 2005 and forward, DMVs have been introduced to get this information.  So to get the contents of the plan cache along with usage statistics, you may use the following DMV script.

Script # 2: Get SQL Server plan cache contents and their usage for SQL Server 2005 and onwards

USE master
GO
SELECT UseCounts,RefCounts, Cacheobjtype, Objtype, 
ISNULL(DB_NAME(dbid),'ResourceDB') AS DatabaseName, TEXT AS SQL 
FROM sys.dm_exec_cached_plans 
CROSS APPLY sys.dm_exec_sql_text(plan_handle) 
ORDER BY dbid,usecounts DESC;
GO

Following is a partial result set from script #2  for SQL Server 2005.

The overall fields used in the above scripts along with their description are as follows:

By using the above scripts you can gain insight into the objects along with their usage frequency in SQL Server. Remember for SQL Server 2000 you need to use the system table syscacheobjects and for SQL Server 2005 and onwards the DMV sys.dm_exec_cached_plans is used primarily.

While testing or troubleshooting you may need to clear the plan cache. You can use the following two commands for this purpose.

Script # 3: Clear whole SQL Server plan cache

DBCC FREEPROCCACHE 
GO

Script #4: Clear SQL Server plan cache for a specific database

DBCC FLUSHPROCINDB (<dbid>)
GO
/*
You can get DBID through following command
Select dbid from sysdatabases where name = <'DBName'>
*/

Beside the above commands, the following operations will also flush the entire plan cache and new batches will require new plans.

• Detaching any database
• Upgrading any database to compatibility level 90 or above on SQL Server 2005 or above
• Running ALTER DATABASE ... MODIFY FILEGROUP command for any database
• Running ALTER DATABASE ... COLLATE command for modifying collation of any database

Altering a database with any of the following commands will remove all plans cached for that specific database.

• ALTER DATABASE ..... MODIFY NAME
• ALTER DATABASE ..... SET ONLINE
• ALTER DATABASE ..... SET OFFLINE
• ALTER DATABASE ..... SET EMERGENCY

The following operations will also remove cached plans for a specific database.

• Dropping a database
• Database is auto closed

It is relevant to mention here that there is no way to remove just a single query plan from the cache for SQL 2005 and below, but for SQL 2008 this is now possible.  Take a look at this article.

Next Steps

• Start digging deeper into your database activity to see what plans are cached and how often queries are being used.
• Stay tuned for other tips about performance tuning.
• Take a look at these other performance tuning related tips.

About the author

Atif Shehzad is a passionate SQL Server DBA, technical reviewer and article author.

This author pledges the content of this article is based on professional experience and not AI generated.

View all my tips