导读:本期聚焦于小黄人创作的《如何查看Oracle数据库RAC集群中ASM磁盘组的total和free mb空间?》,敬请观看详情。在Oracle RAC环境中,ASM磁盘组的空间使用状况直接影响数据库可用性。不少运维人员误以为用操作系统df命令就能掌握存储余量,其实ASM管理的裸设备并不反映在传统文件系统中。正确做法是通过ASM实例的V$ASM_DISKGROUP视图查询total_mb与free_mb字段,这两个值以兆字节为单位分别表示磁盘组总容量和剩余容量。也可以借助asmcmd的lsdg命令在命令行快速获取。当free_mb持续走低时需警惕重新平衡失败或文件无法扩展的风险,尤其是多租户场景下更容易突发空间耗尽。理解total_mb与usable_file_mb的差异也十分重要,后者扣除了冗余所需空间,更能体现真实可用量。

在Oracle RAC集群里,ASM(Automatic Storage Management)负责统一管理底层存储,并以磁盘组为单位向数据库提供文件空间。很多刚接触集群环境的工程师会困惑:明明操作系统层面看不到对应挂载点,该怎么掌握每个磁盘组的总量和剩余量?其实ASM自身维护了完整的空间视图,只要连接到ASM实例就能直接读取。掌握total_mb和free_mb不仅是为了监控,更是容量规划和故障预防的基础。

如何查看Oracle数据库RAC集群中ASM磁盘组的total和free mb空间?

通过SQL视图查询ASM磁盘组空间

最直接可靠的方式是登录到ASM实例,查询动态性能视图V$ASM_DISKGROUP。这个视图中NAME列代表磁盘组名称,TOTAL_MB表示分配给该磁盘组的全部空间,单位为MB,FREE_MB则是当前未被使用的空间。在RAC环境中,每个节点的ASM实例都能看到一致的集群级视图,因此无论连到哪个节点查询结果都相同。

除了基础字段,USABLE_FILE_MB也值得关注。对于普通冗余(mirror)或高冗余(high)磁盘组,由于数据副本占用,FREE_MB并不能等同于业务可写入空间,USABLE_FILE_MB扣除了冗余要求后才是真实可用量。下面是一段典型的查询语句,可以同时输出多项指标:

SELECT
  name            AS diskgroup_name,
  total_mb        AS total_mb,
  free_mb         AS free_mb,
  usable_file_mb  AS usable_file_mb,
  round((free_mb / total_mb) * 100, 2) AS free_pct
FROM v$asm_diskgroup
ORDER BY name;

执行上述语句后,如果FREE_MB接近零但USABLE_FILE_MB为负值,说明冗余空间已经不足以支撑正常写入,数据库可能报错ORA-15041。此时应当及时扩容磁盘或清理过期文件。相比在数据库实例中查DBA_DATA_FILES,ASM视图反映的是存储层真实情况,不会被表空间逻辑结构误导。

使用asmcmd命令行工具快速获取

如果不方便打开SQL会话,ASM自带的管理工具asmcmd提供了更轻量的查看方式。在操作系统提示符下输入asmcmd lsdg即可列出所有磁盘组的状态,其中Total_MBFree_MB列和视图字段一一对应。这个命令本质上是封装了对V$ASM_DISKGROUP的查询,但输出更紧凑,适合写进Shell监控脚本。

在实际运维中,我们可以配合grepawk做阈值告警。例如只提取DATA磁盘组的剩余空间,当小于某个数值时触发邮件。下面示例展示如何用Shell调用asmcmd并解析:

#!/bin/bash
# 获取DATA磁盘组free_mb
free=$(asmcmd lsdg DATA | awk 'NR==2 {print $6}')
if [ "$free" -lt 51200 ]; then
  echo "DATA磁盘组剩余空间不足50G,当前free_mb=$free" | mail -s "ASM空间告警" dba@ipipp.com
fi

需要注意的是,asmcmd必须在Grid Infrastructure属主用户(通常是grid)环境下执行,且依赖正确的ORACLE_HOME与ORACLE_SID设置。如果报错连不上ASM实例,先检查ora.cssdora.asm资源是否在线。相比SQL方式,命令行更适合自动化,但在复杂容量分析时仍建议回到视图查询。

空间监控中的常见误区与优化建议

一个广泛存在的误区是拿操作系统df -h去判断ASM磁盘组余量。由于ASM通常直接使用裸盘或ASMlib设备,文件系统层看不到对应条目,即便看到也是asm挂载点且数值不代表业务可用量。另一误区是只盯TOTAL_MBFREE_MB比值,忽略冗余类型。例如高冗余下三副本意味着1MB数据实际消耗3MB,FREE_MB下降速度会明显快于数据写入量。

从架构角度,RAC中所有节点共享同一套ASM磁盘组,任一节点的空间耗尽都会波及全局。因此监控不能只在一台机器上做,而应集中采集。可建立定时任务,每分钟从任一存活节点取V$ASM_DISKGROUP写入监控库,再用Grafana等展示。同时设置分级告警:FREE_PCT低于20%提示,低于10%严重,低于5%立即处理。以下SQL可用于生成历史趋势基础数据:

INSERT INTO asm_space_hist
SELECT sysdate, name, total_mb, free_mb, usable_file_mb
FROM v$asm_diskgroup;

当确实需要扩容时,向磁盘组添加新盘后ASM会自动触发重平衡(rebalance),此过程会暂时降低FREE_MB可用速度并增加IO负载。建议在业务低峰期操作,并通过V$ASM_OPERATION视图跟踪进度。合理规划初始磁盘组大小、选择合适的冗余策略,才能让total与free mb始终处于健康区间,保障RAC集群长期稳定运行。

Oracle_RACASM磁盘组total_mb修改时间:2026-08-17 10:42:35

免责声明:​ 已尽一切努力确保本网站所含信息的准确性。网站内容多为原创整理与精心编撰,观点力求客观中立。本站旨在免费分享,内容仅供个人学习、研究或参考使用。若引用了第三方作品,版权归原作者所有。如内容涉及您的权益,请联系我们处理。
内容垂直聚焦
专注技术核心技术栏目,确保每篇文章深度聚焦于实用技能。从代码技巧到架构设计,为用户提供无干扰的纯技术知识沉淀,精准满足专业提升需求。
知识结构清晰
覆盖从开发到部署的全链路。AI、前端、编程、数据库、服务器、建站、系统层层递进,构建清晰学习路径,帮助用户系统化掌握开发与运维所需的核心技术。
深度技术解析
拒绝泛泛而谈,深入技术细节与实践难点。无论是数据库优化还是服务器配置,均结合真实场景与代码示例进行剖析,致力于提供可直接应用于工作的解决方案。
专业领域覆盖
精准对应开发生命周期。从前端界面到后端编程,从数据库操作到服务器运维,形成完整闭环,一站式满足全栈工程师和运维人员的技术需求。
即学即用高效
内容强调实操性,步骤清晰、代码完整。用户可根据教程直接复现和应用于自身项目,显著缩短从学习到实践的距离,快速解决开发中的具体问题。
持续更新保障
专注既定技术方向进行长期、稳定的内容输出。确保各栏目技术文章持续更新迭代,紧跟主流技术发展趋势,为用户提供经久不衰的学习价值。