O mais provável é que tenha sido causado por uma consulta que deseja ler mais páginas no buffer pool e que o buffer pool obtenha mais memória para acomodar isso. É assim que o SQL Server deve funcionar. Se a caixa sofrer pressão de memória, ela solicitará ao SQL Server que desista de alguma memória, o que ela fará. O cliente não deve se preocupar.
Você pode usar o DMV sys.dm_os_buffer_descriptors
para ver quanto da memória do buffer pool está sendo usada por qual banco de dados. Esse snippet 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 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
Eu explico isso um pouco mais neste post de blog Dentro do Mecanismo de Armazenamento: O que há no buffer pool?
Você também pode fazer o checkout em KB 907877 ( Como usar o comando DBCC MEMORYSTATUS para monitorar o uso da memória no SQL Server 2005 ) que lhe dará uma idéia da divisão do restante do uso de memória do SQL Server (mas não por banco de dados).
Espero que isso ajude!