Новое в SQL Server 2025: sys.dm_os_memory_health_history

Автор: SQLYARD, Meet sys.dm_os_memory_health_history in SQL Server 2025

В SQL Server 2025 компания Microsoft представила новое динамическое административное представление (DMV) sys.dm_os_memory_health_history. Ключевые моменты:

• Оно фиксирует снимки состояния использования и «здоровья» памяти во времени.
• Каждая строка — это один снимок.
• Снимки содержат различные метрики: сколько памяти доступно для новых распределений, сколько используется освобождаемыми кешами, какие диспетчеры памяти потребляют больше всего, а также «уровень серьёзности», показывающий, насколько здоровым (или перегруженным) является состояние памяти.
• Это функция в режиме предварительного просмотра — схема или поведение могут измениться в будущих обновлениях SQL Server 2025. 

Почему это важно

Работая с SQL Server понимаешь, что диагностика проблем с памятью — одна из самых сложных задач: иногда всё выглядит нормально, пока внезапно не начнутся проблемы. Традиционные метрики (размер буферного пула, ожидаемое время жизни страницы, статистика ожиданий и т. д.) дают лишь фрагменты картины и часто только после того, как симптомы уже стали заметны.

sys.dm_os_memory_health_history даёт вам:

• Непрерывный обзор состояния памяти во времени, а не точечные метрики.
• Своего рода систему раннего предупреждения: уровни серьёзности, потенциал распределения, наиболее активные диспетчеры памяти — всё это помогает заметить проблемы до того, как они станут критическими.
• Возможность понять, какие компоненты используют память (через диспетчеры памяти), чтобы выявить возможных «виновников».
• Лучший контекст: сколько памяти можно освободить, а сколько уже выделено под использование, не связанное с кешем и не подлежащее освобождению.

Короче говоря: получаем больше данных, узнаём о проблемах раньше, и приобретаем больше пользы для дальнейших действий.

Важные столбцы и их значение

Ниже приведены основные столбцы DMV и их объяснения. 

Столбец	Тип данных	Что означает / зачем нужен
snapshot_time	datetime2	Время создания снимка. Полезно для упорядочивания и анализа трендов.
allocation_potential_memory_mb	int	Сколько памяти доступно для новых распределений. Падение этого значения — ранний сигнал нехватки памяти.
external_cache_mb	int	Память, используемая освобождаемыми кешами (буферный пул, columnstore и т. д.). Высокие значения означают, что SQL может освободить пространство при необходимости.
top_clerks	nvarchar(4000), JSON	JSON-список наиболее «прожорливых» диспетчеров памяти. Позволяет понять, какие компоненты потребляют ресурсы.
severity_level	tinyint	Индикатор состояния: 1 = низкий уровень, 2 = средний, 3 = высокий. Удобно для быстрого выявления ухудшений.

Снимки создаются примерно каждые 15 секунд, и SQL Server хранит до 256 снимков. Более старые удаляются. При перезапуске службы или движка данные сбрасываются.

Примеры: от новичка до эксперта

Новичок: просто посмотреть текущее состояние

Если вы только начинаете или хотите быстро увидеть последнее состояние памяти:

SELECT TOP 10
    snapshot_time,
    severity_level AS Severity,
    allocation_potential_memory_mb AS AllocationPotentialMB,
    external_cache_mb AS ReclaimableCacheMB
FROM sys.dm_os_memory_health_history
ORDER BY snapshot_time DESC;

На что обратить внимание:

• Не слишком ли мало (или не падает ли) allocation_potential_memory_mb?
• Бывает ли severity_level равным 2 или 3?
• Не снижается ли резко освобождаемый кеш?

Средний уровень: какие диспетчеры памяти используются больше всего

Если видите признаки проблем, полезно узнать, почему. Для этого анализируем JSON в поле top_clerks:

SELECT
    mh.snapshot_time,
    mh.severity_level,
    mh.allocation_potential_memory_mb,
    clerk.clerk_type,
    clerk.pages_allocated_kb
FROM sys.dm_os_memory_health_history AS mh
CROSS APPLY
    OPENJSON(mh.top_clerks)
    WITH (
       clerk_type sysname '$.clerk_type',
       pages_allocated_kb bigint '$.pages_allocated_kb'
    ) AS clerk
ORDER BY mh.snapshot_time DESC, clerk.pages_allocated_kb DESC;

Это позволяет понять, какие именно диспетчеры (буферный пул, columnstore, рабочая область запросов и т. д.) потребляют память во времени.

Средний+ уровень: тренды и оповещения

Вместо того чтобы смотреть только на «сырые» данные, можно строить тренды или правила для оповещений:

• Считать скользящие средние по allocation_potential_memory_mb за последние несколько снимков (например, за 5 минут).
• Если severity_level = 3 более X снимков подряд — отправлять оповещение.
• Сравнивать освобождаемый кеш и общий кеш, чтобы понять, когда SQL реально начинает освобождать память.

;WITH Recent AS (
  SELECT TOP (20)
     snapshot_time,
     severity_level,
     allocation_potential_memory_mb,
     external_cache_mb
  FROM sys.dm_os_memory_health_history
  ORDER BY snapshot_time DESC
)
SELECT
   MAX(snapshot_time) AS LastSnapshot,
   MIN(allocation_potential_memory_mb) AS MinAllocPotential,
   AVG(allocation_potential_memory_mb) AS AvgAllocPotential,
   MAX(external_cache_mb) AS MaxReclaimableCache,
   SUM(CASE WHEN severity_level = 3 THEN 1 ELSE 0 END) AS HighSeverityCount
FROM Recent;

Пример правила: если HighSeverityCount > 3 (т. е. три снимка подряд с высоким уровнем), стоит немедленно разбираться.

Эксперт: объединение с другими DMV, планирование ёмкости и поиск причин

На экспертном уровне стоит объединять данные об «истории потребления памяти» с другими системными сведениями и историей нагрузки, чтобы не только реагировать на проблемы, но и предотвращать их, настраивать параметры и планировать будущее.

Некоторые идеи:

• Соединить с sys.dm_os_memory_clerks или sys.dm_os_memory_nodes_processor_groups, чтобы проверить, какие диспетчеры стабильно загружают память.
• Следить за ожиданиями распределения памяти запросами (sys.dm_exec_query_memory_grants) — если падает allocation_potential, не ждут ли запросы?
• Смотреть поведение ввода-вывода (логические и физические чтения/записи). При нехватке памяти будет больше физических чтений.
• Анализировать настройки Resource Governor: согласуются ли они с наблюдаемыми нагрузками?
• Прогнозировать масштабирование: на основе пиковых нагрузок и трендов принимать решения о железе или конфигурации до возникновения проблем.

-- Найти запросы, ожидавшие память, когда allocation potential был низким
;WITH LowAlloc AS (
  SELECT TOP(100)
    snapshot_time,
    allocation_potential_memory_mb,
    severity_level
  FROM sys.dm_os_memory_health_history
  WHERE allocation_potential_memory_mb < 1000 -- порог зависит от размера сервера
    AND severity_level >= 2
  ORDER BY snapshot_time DESC
)
SELECT
   la.snapshot_time,
   la.allocation_potential_memory_mb,
   mg.requested_memory_kb,
   mg.granted_memory_kb,
   mg.status
FROM LowAlloc AS la
JOIN sys.dm_exec_query_memory_grants AS mg
  ON mg.requested_time BETWEEN la.snapshot_time AND DATEADD(SECOND,15, la.snapshot_time)
ORDER BY la.snapshot_time DESC, mg.requested_memory_kb DESC;

Это связывает периоды плохого состояния памяти с конкретными запросами, что важно для расследования проблем SLA или производительности.