sys.dm_os_memory_health_history

适用于:SQL Server 2025 (17.x) 在Microsoft Fabric 中预览 Azure SQL 数据库Azure SQL 托管实例 SQL 数据库

注意

动态 sys.dm_os_memory_health_history 管理视图处于预览状态。 架构和提供的数据可能会更改。

为数据库引擎实例提供内存运行状况快照。 每行表示最近内存使用情况的快照,其中包括内存运行状况问题的严重性(如果有)。

有关排查Azure SQL 数据库内存不足的详细信息,请参阅Azure SQL 数据库中的内存不足错误疑难解答。

在Azure SQL 托管实例中,此视图仅在具有最新更新策略的实例上可用。

列名称 数据类型 描述
snapshot_time datetime2 快照时间。 可以为 NULL。
allocation_potential_memory_mb int 可用于数据库引擎实例的新分配的内存(以 MB 为单位)。 不可为 null。
external_cache_mb int 可回收缓存(如缓冲池和列存储对象池)使用的内存(以 MB 为单位)。 在内存压力下,数据库引擎可能会收缩这些缓存以在其他位置使用内存。 不可为 null。
top_clerks nvarchar(4000) 内存消耗量最高的内存职员,包括每个职员的内存使用情况统计信息。 此信息以 JSON 值的形式提供。 可以为 NULL。
severity_level tinyint 描述内存运行状况问题的严重性的值。 不可为 null。

1 - Low
未识别内存运行状况问题。

2 - Medium
内存运行状况问题可能存在中等置信度。 某些尝试分配内存可能会失败。 数据缓存可能会收缩,因此磁盘 I/O 可能会增加。

3 - High
内存运行状况问题存在高度置信度。 可用内存可能不足,新的内存分配尝试可能会失败,磁盘 I/O 可能会大幅增加,因为剩余数据缓存的大小太小。

权限

在 SQL Server 和 Azure SQL 托管实例中,需要 VIEW SERVER PERFORMANCE STATE 权限。

在 SQL 数据库基本S0S1 服务目标中,对于弹性池中的数据库,需要服务器管理员帐户、Microsoft Entra 管理员帐户或##MS_ServerPerformanceStateReader##的成员身份。 在所有其他 SQL 数据库服务目标中, VIEW DATABASE PERFORMANCE STATE 需要对数据库的权限或服务器角色的成员 ##MS_ServerPerformanceStateReader## 身份。

注解

快照大约每 15 秒添加一次,总共最多 256 个快照。 添加较新的快照时,会删除较旧的快照。 当数据库引擎重新启动时,此视图中的数据将重置。

例子

答: 获取所有可用的内存运行状况快照

此示例返回按快照时间排序的所有内存运行状况快照行。

SELECT snapshot_time,
       severity_level,
       allocation_potential_memory_mb,
       reclaimable_cache_memory_mb,
       top_memory_clerks
FROM sys.dm_os_memory_health_history
ORDER BY snapshot_time DESC;

B. 获取每个快照中的顶级内存职员

本示例将列中的 JSON 数据 top_memory_clerks 扩展到每个快照的各个行中。 结果集中的每一行都表示特定内存运行状况快照中的顶级内存职员。

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