For many people, the way that SQL Server uses memory can be a bit of an enigma. A large percentage of the memory your SQL Server instance utilizes is consumed by buffer pool (essentially, data). Without a lot of digging, it can be hard to tell which of your databases consume the most buffer pool memory, and even more so, which objects within those databases. This information can be quite useful, for example, if you are considering an application change to split your database across multiple servers, or trying to identify databases that are candidates for consolidation.
A Dynamic Management View (DMV) introduced in SQL Server 2005, called sys.dm_os_buffer_descriptors, contains a row for every page that has been cached in the buffer pool. Using this DMV, you can quickly determine which database(s) are utilizing the majority of your buffer pool memory. Once you have identified the databases that are occupying much of the buffer pool, you can drill into them individually. In the following query, I first find out exactly how big the buffer pool currently is (from the DMV sys.dm_os_performance_counters), allowing me to calculate the percentage of the buffer pool being used by each database:
-- Note: querying sys.dm_os_buffer_descriptors
-- requires the VIEW_SERVER_STATE permission.
DECLARE @total_buffer INT;
SELECT @total_buffer = cntr_value
WHERE RTRIM([object_name]) LIKE '%Buffer Manager'
AND counter_name = 'Database Pages';
;WITH src AS
database_id, db_buffer_pages = COUNT_BIG(*)
--WHERE database_id BETWEEN 5 AND 32766
GROUP BY database_id
[db_name] = CASE [database_id] WHEN 32767
THEN 'Resource DB'
ELSE DB_NAME([database_id]) END,
db_buffer_MB = db_buffer_pages / 128,
db_buffer_percent = CONVERT(DECIMAL(6,3),
db_buffer_pages * 100.0 / @total_buffer)
ORDER BY db_buffer_MB DESC;
In the above query, I've included the system databases, but you can exclude them by uncommenting the WHERE clause within the CTE. Note that the actual filter may need to change with future versions of SQL Server; for example, in SQL Server 2012, there is a new database for Integration Services called SSISDB. You may want to keep an eye on system databases just to have a complete picture, seeing as there isn't much you can do about their buffer pool usage anyway - unless you are using master or msdb for your own custom objects.
That all said, here are partial results from an instance on my local virtual machine:
Clearly, the SQLSentry database - while only representing 258 MB - occupies about 70% of my buffer pool for this instance. So now I know that I can drill into that database specifically if I want to track down the objects that are taking up most of that memory. You can once again use the sys.dm_os_buffer_descriptors only this time, instead of aggregating the page counts at the database level, we can utilize a set of catalog views to determine the number of pages (and therefore amount of memory) dedicated to each object.
;WITH src AS
[Object] = o.name,
[Type] = o.type_desc,
[Index] = COALESCE(i.name, ''),
[Index_Type] = i.type_desc,
sys.partitions AS p
sys.allocation_units AS au
ON p.hobt_id = au.container_id
sys.objects AS o
ON p.[object_id] = o.[object_id]
sys.indexes AS i
ON o.[object_id] = i.[object_id]
AND p.index_id = i.index_id
au.[type] IN (1,2,3)
AND o.is_ms_shipped = 0
buffer_pages = COUNT_BIG(b.page_id),
buffer_mb = COUNT_BIG(b.page_id) / 128
sys.dm_os_buffer_descriptors AS b
ON src.allocation_unit_id = b.allocation_unit_id
b.database_id = DB_ID()
Here are the results from this database. Notice that I've captured both clustered and non-clustered indexes, for clustered tables and heaps, and for illustrative purposes I have also created an indexed view.
Please keep in mind that the buffer pool is in constant flux, and that this latter query has explicitly filtered out system objects, so the numbers won't always add up nicely. Still, this should give you a fairly good idea of which objects are using your buffer pool the most.
When investigating the performance of your servers, buffer pool data is only a part of the picture, but it's one that is often overlooked. Including this data will help you to make better and more informed decisions about direction and scale.
Take an inventory of the highest buffer pool consumers on your servers, and see if the results surprise you.
Make a plan to periodically review this information and watch for significant changes.
Tempting article, however, shouldn't the summation of the db_buffer_percent = 100 ... it's not for my SQL instance. the summatoin is just 79%. although i didn't include any filter. I've just ran the query as it is! ... where is the rest 21%?!
Wednesday, June 03, 2015 - 12:21:54 PM - coolcancer
This is great information. The memory is out the roof on one of my 2012 SP2 servers. Its causing issues and I'm trying to determine if there is a memory leak and if so, which procedures might be causing it. If you have any past articles on that, I'd love to read them.
Tuesday, November 18, 2014 - 4:55:35 AM - Will Smith
Great Post indeed and I used this several time to identify the Databasewise Memory usage on a SQL Server Instance.
While recently using this DatatabaseWise Memory usage query, on the result window, the tempdb is consuming around 2+ Gigs of Memory.
I also used the object wise memory usage query to identify the memory usage of Tempdb. But from the result set I am not getting the details of the entire 2 Gigs of Memory usage that was shown on the result of Databasewise Memory usage.
May I request to shed some light about the Tempdb Memory usage on SQL Server 2008 and how to remove the memory usage with out restarting the instance ?
Thanks in advance
Tuesday, March 19, 2013 - 4:56:33 PM - Aaron Bertrand
Ammad not really an easy way through the DMVs directly unless you parse the plan cache for any currently running queries and determine it that way - however that may actually cause more performance problems than you could possibly hope to solve.
If you want to know who is querying specific tables, that might be a better job for trace, audit, or 3rd party monitoring like SQL Sentry Performance Advisor.