Скорее всего, это вызвано запросом, желающим прочитать больше страниц в буферный пул, и буферный пул захватывает больше памяти, чтобы приспособиться к этому. Вот как SQL Server должен работать. Если ящик испытывает нехватку памяти, он попросит SQL Server освободить часть памяти, что он и сделает. Клиент не должен быть обеспокоен.
Вы можете использовать DMV, sys.dm_os_buffer_descriptors
чтобы увидеть, какой объем памяти буферного пула используется какой базой данных. Этот фрагмент расскажет вам, сколько чистых и грязных (измененных с момента последней контрольной точки или чтения с диска) страниц из каждой базы данных находятся в пуле буферов. Вы можете изменить дальше.
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
Я объясню это немного подробнее в этой записи блога Inside the Storage Engine: Что находится в пуле буферов?
Вы также можете проверить KB 907877 ( Как использовать команду DBCC MEMORYSTATUS для мониторинга использования памяти в SQL Server 2005 ), которая даст вам представление о разбивке остальной части использования памяти SQL Server (но не для каждой базы данных).
Надеюсь это поможет!