在Oracle RAC环境中，ASM（Automatic Storage Management）负责数据库共享存储的分配与管理，v$asm_diskgroup是ASM实例中最重要的动态性能视图之一。该视图记录了每个磁盘组的组号、名称、挂载状态、冗余类型、总空间、空闲空间以及镜像所需空间等关键指标。DBA平时做空间监控、故障判断，都离不开这个视图。但有一个容易忽略的点：RAC中每个节点都运行独立的ASM实例，每个实例的v$asm_diskgroup只反映本节点所看到的状态，因此多节点查询时需要用到GV$ASM_DISKGROUP。在Windows平台，Grid Infrastructure默认安装路径为C:\app\grid\product\19.0.0\grid_1，ASM相关的sqlplus.exe就位于该目录的bin子目录下，连接方式为sqlplus / as sysasm。
一、v$asm_diskgroup关键字段与RAC环境下的特殊表现
先看几个最常用的字段。GROUP_NUMBER是磁盘组在ASM实例内的编号，NAME是磁盘组名称，STATE表示磁盘组当前状态，常见的值包括CONNECTED、MOUNTED、DISMOUNTED、BROKEN等。只有STATE为MOUNTED或CONNECTED时，磁盘组才能为数据库提供正常的存储服务。TYPE字段表示冗余类型，EXTERN表示外部冗余，NORMAL表示两路镜像，HIGH表示三路镜像。TOTAL_MB和FREE_MB分别是磁盘组的总物理容量和当前空闲物理容量。REQUIRED_MIRROR_FREE_MB表示为了容忍一个故障组失效而需要预留的空闲空间，USABLE_FILE_MB则是扣除镜像开销后真正可用于数据文件扩展的空间。OFFLINE_DISKS表示当前处于离线状态的磁盘数量。
在RAC环境中，这些字段的表现会因节点不同而有所差异。例如，某个节点上的ASM实例可能因为网络或存储链路问题，无法访问到部分磁盘，导致它看到的磁盘组STATE为DISMOUNTED，而其他节点却正常。此时的v$asm_diskgroup结果只代表单个节点的视角，不能反映整个集群的存储状态。因此在做集中监控时，应当优先查询GV$ASM_DISKGROUP，并关注INST_ID字段来区分节点。
举个简单的例子，在Windows节点上打开命令行工具，进入到C:\app\grid\product\19.0.0\grid_1\bin目录，执行sqlplus / as sysasm登录ASM实例后，运行如下语句即可查看当前节点所有磁盘组概要信息。
SELECT group_number, name, state, type, total_mb, free_mb,
required_mirror_free_mb, usable_file_mb, offline_disks
FROM v$asm_diskgroup
ORDER BY group_number;
这段SQL没有使用大于号等特殊字符，所以无需转义。实际使用时如果加上过滤条件，比如WHERE total_mb > 0，需要在代码块中对比较运算符进行HTML转义，避免HTML解析错误。
二、跨节点查询：用GV$视图获取全局磁盘组状态
RAC集群中，每个节点的ASM实例都维护一份v$asm_diskgroup，但共享存储上的磁盘组元数据是全局一致的。GV$ASM_DISKGROUP就是在所有节点v$视图的基础上增加了一个INST_ID字段，用来标识行来自哪个实例。通过查询GV$ASM_DISKGROUP，DBA可以在一张结果集里看到每个节点对同一个磁盘组的挂载状态，快速判断是否出现节点间不一致的情况。
SELECT inst_id, name, state, type, total_mb, free_mb, usable_file_mb FROM gv$asm_diskgroup ORDER BY inst_id, group_number;
上面这条SQL如果发现同一个NAME在不同INST_ID下STATE有差异，比如节点1是MOUNTED，节点2是DISMOUNTED，通常说明节点2的ASM实例存在存储链路或权限问题。此时可以先在节点2上检查磁盘组挂载状态，使用srvctl命令查看ASM实例运行情况。Windows下可以运行C:\app\grid\product\19.0.0\grid_1\bin\srvctl.exe status asm -node racnode2，如果ASM实例正常，再检查asm_diskstring参数是否能够发现对应磁盘。
另外，GV$视图也常用于分析ASM实例间的缓存一致性。比如某些节点上的FREE_MB更新滞后，可能是ASM实例的后台进程DBWR或RBAL没有及时刷新统计信息。虽然这类情况不多，但在压力较大或存储响应变慢时会出现，因此在排查空间问题时最好结合GV$视图和磁盘级视图一起查看。
三、从FREE_MB到USABLE_FILE_MB：真实可用空间如何计算
很多DBA习惯直接看FREE_MB，认为这个值就是还能分配给数据文件的量，这其实是一个常见误区。FREE_MB是物理层面的空闲空间总和，没有考虑ASM冗余策略带来的镜像开销。对于NORMAL冗余的磁盘组，每写入一份数据，ASM都会在另一个故障组中写入一份镜像副本，所以实际占用的物理空间是数据大小的两倍。HIGH冗余则是三倍。因此FREE_MB看起来很大，但真正能用于数据文件扩展的USABLE_FILE_MB可能小得多。
还需要注意REQUIRED_MIRROR_FREE_MB这个字段。它的作用是保证在某个故障组整体失效时，ASM仍有足够空间重新建立镜像。这个预留空间平时不能被普通数据文件使用。举例来说，一个NORMAL冗余磁盘组共有100GB物理空间，已使用60GB，FREE_MB显示40GB，但REQUIRED_MIRROR_FREE_MB为20GB，那么USABLE_FILE_MB大约只有20GB。如果再减去一些元数据开销，实际可分配空间还会略低。下面这条SQL可以直观看到三者关系：
SELECT name, type, total_mb, free_mb, required_mirror_free_mb,
usable_file_mb, round((usable_file_mb / total_mb) * 100, 2) AS pct_usable
FROM v$asm_diskgroup
WHERE total_mb > 0
ORDER BY pct_usable;
注意上面代码中的比较运算符已经做了HTML转义，在网页展示时不会破坏代码块结构。ASM的USABLE_FILE_MB并不是简单等于FREE_MB减去REQUIRED_MIRROR_FREE_MB，实际还会受到每个磁盘可用空间分布的影响。如果磁盘组的AU（Allocation Unit）大小设置过大，或者各磁盘间空间分布不均，也可能导致某些文件无法分配区，即使整体空间看似充足。因此监控时最好结合v$asm_disk视图，查看每个磁盘的FREE_MB和磁盘状态。
四、磁盘组离线与空间不足的排查思路
当v$asm_diskgroup中某个磁盘组STATE变为DISMOUNTED或者OFFLINE_DISKS大于0时，需要快速定位原因。第一步就是确认是单个节点问题还是整个集群问题。如果只有一个节点DISMOUNTED，可以先检查该节点的ASM实例是否正常，然后查看操作系统层面磁盘是否可见。在Windows环境中，ASM使用的磁盘可能是通过ASMLib或直接使用裸设备，磁盘路径通常类似\\.\ORCLDISK1，或者通过符号链接指向物理磁盘。检查asm_diskstring参数设置是否包含正确的搜索路径即可快速判断。路径中的反斜杠必须保留，例如参数值为C:\oracle\asmdisks\*。
如果磁盘组在所有节点都显示DISMOUNTED，就要检查共享存储本身的可用性，例如光纤交换机、iSCSI目标或者多路径软件状态。对于NORMAL或HIGH冗余磁盘组，单个故障组中的磁盘全部离线通常不会导致磁盘组DISMOUNTED，但会触发REQUIRED_MIRROR_FREE_MB的变化，同时OFFLINE_DISKS计数会增加。这时可以查询v$asm_disk确认具体是哪些磁盘离线，再用ALTER DISKGROUP命令将它们重新上线。
SELECT dg.name AS diskgroup_name, d.name AS disk_name, d.path, d.state, d.mount_status FROM v$asm_diskgroup dg JOIN v$asm_disk d ON dg.group_number = d.group_number WHERE dg.state <> 'MOUNTED' OR d.state <> 'NORMAL' ORDER BY dg.name, d.name;
上面这条SQL用于查找状态异常的磁盘，注意代码中的小于号和大于号已经按照HTML规范做了转义。通过v$asm_disk的PATH字段，可以发现在Windows下ASM磁盘的路径格式，例如\\.\PhysicalDrive1或者某个分区路径，结合操作系统磁盘管理工具进一步分析。
空间不足的情况则相对直接。当数据库报错ORA-15041或者无法扩展数据文件时，先查v$asm_diskgroup的USABLE_FILE_MB是否已经接近0。如果确实不足，可以通过添加磁盘、删除无用文件、调整冗余策略或者将部分数据文件迁移到其他磁盘组来释放空间。需要注意的是，在RAC环境中执行ALTER DISKGROUP ADD DISK操作时，要求所有节点的ASM实例都能访问到新添加的磁盘路径，否则会导致命令在部分节点上失败。Windows下添加磁盘前最好先在每个节点用asmcmd或者sqlplus检查磁盘可见性。
SELECT name, total_mb, free_mb, required_mirror_free_mb, usable_file_mb FROM v$asm_diskgroup WHERE usable_file_mb < 1024 ORDER BY usable_file_mb;
这条SQL找出所有可用空间小于1GB的磁盘组，适合放到监控脚本中做告警。查询条件中的小于号同样需要转义后才能写入HTML代码块。将查询命令写成脚本，在Windows的计划任务中定时执行，结果异常时通过邮件通知DBA，是一种实用的运维手段。
总结来说，v$asm_diskgroup视图虽然字段不多，但每个字段都承载着ASM存储管理的核心信息。在RAC环境下使用它时，要结合GV$视图区分节点，理解FREE_MB与USABLE_FILE_MB的差异，并关注磁盘组状态和离线磁盘数量。养成定期查看这些指标的习惯，可以帮助DBA提前发现存储隐患，避免因空间不足或磁盘故障导致数据库停机。
Oracle RACASM磁盘组v$asm_diskgroup修改时间：2026-09-18 21:31:18