Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is it possible to get a break down of how many plan cache pages are being used per database? Perfmon seems to only have the total for the server, but maybe there is a DMV with more detail?

Also, does the buffer pool (sys.dm_os_buffer_descriptors) include the plan cache or is that separate?

share|improve this question

Here are queries that will give you buffer breakdown and plan cache breakdown per database. Note that plan cache is broken down by MB, not by pages - I don't know of a handy way, off the top of my head, to calculate the pages used by the plan cache (you'd think it's simple division, but not necessarily).

-- buffer pool breakdown

  db = DB_NAME(database_id),
  c = COUNT(DISTINCT page_id),
  size_MB = CONVERT(DECIMAL(12,2), COUNT(DISTINCT page_id)*8.0/1024) 
FROM sys.dm_os_buffer_descriptors
WHERE database_id < 32767
GROUP BY database_id

-- plan cache breakdown

  db = DB_NAME(t.[dbid]), 
  size_MB = CONVERT(DECIMAL(12,2), SUM(p.size_in_bytes)/1024.0/1024)
FROM sys.dm_exec_cached_plans AS p
CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS t
WHERE t.[dbid] < 32767
GROUP BY t.[dbid]

On my test instance there are cases where plan cache is larger than the buffer pool for a given database.

The buffer pool contains both the data cache and the plan cache. But AFAIK sys.dm_os_buffer_descriptors only contains information about the data cache (index and data pages), so it does not necessarily reflect the entire buffer pool. The cases I saw above seem to support that theory.

share|improve this answer
use db1;
select ... 
from db2..table
join db3..table;

Should the memory allocated for this plan be counted against db1, db2 or db3? Usually the three dbs in my example are the same and the issue is not perceived, but the problem is there none the less and this is why a view like sys.dm_exec_cached_plans does not project database_id, and sys.dm_exec_query_plan has the note:

For ad hoc and prepared SQL statements, the ID of the database where the statements were compiled.

The thinking around this issues should be 'memory allocated for plans', 'memory allocated for execution' and don't consider such memory as 'pages'. This is even more so in the SQL Server 2012 memory model which makes the buffer pool and ordinary client of the memory broker.

For 'data' is all clear: a data page has an obvious database is coming from and sys.dm_os_buffer_descriptors will describe it exactly.

And for the second question: sys.dm_os_buffer_descriptors will only show data, not stolen pages.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.