Provavelmente, foi causada por uma consulta que desejava ler mais páginas no buffer pool e o buffer pool capturou mais memória para acomodar isso. É assim que o SQL Server deve funcionar. Se a caixa sofrer pressão de memória, solicitará que o SQL Server desista de um pouco de memória, o que fará. O cliente não deve se preocupar.
Você pode usar a DMV sys.dm_os_buffer_descriptors
para ver quanto da memória do buffer pool está sendo usada por qual banco de dados. Esse trecho informará quantas páginas limpas e sujas (modificadas desde o último ponto de verificação ou lidas do disco) de cada banco de dados estão no buffer pool. Você pode modificar ainda mais.
SELECT
(CASE WHEN ([is_modified] = 1) THEN 'Dirty' ELSE 'Clean' END) AS 'Page State',
(CASE WHEN ([database_id] = 32767) THEN 'Resource Database' ELSE DB_NAME (database_id) END) AS 'Database Name',
COUNT (*) AS 'Page Count'
FROM sys.dm_os_buffer_descriptors
GROUP BY [database_id], [is_modified]
ORDER BY [database_id], [is_modified];
GO
Explico isso um pouco mais nesta postagem de blog Por dentro do mecanismo de armazenamento: o que há no buffer pool?
Você também pode fazer o check-out da KB 907877 ( como usar o comando DBCC MEMORYSTATUS para monitorar o uso de memória no SQL Server 2005 ), que lhe dará uma idéia da discriminação do restante do uso de memória do SQL Server (mas não por banco de dados).
Espero que isto ajude!