asmcmd lsdg 的 Free_MB 是逻辑可用空间，非物理剩余空间；Usable_file_MB 才是真实可写上限，Req_mir_free_MB 是冗余保障底线；需按冗余类型归一化计算真实使用率。
直接看 asmcmd lsdg 输出，但别信“Free_MB”那一栏
它显示的是逻辑可用空间，不是物理剩余空间。尤其在 normal 或 high 冗余模式下，free_mb 是按“可写入文件的容量”算的，而底层实际磁盘可能早已吃紧。
-
lsdg中的Usable_file_MB才是真正能存新数据的空间上限（已考虑镜像冗余） -
Req_mir_free_MB表示当前为满足冗余策略必须保留的最小空闲量；低于它会触发告警甚至拒绝写入 - 如果
Usable_file_MB接近 0，哪怕Free_MB还剩几万 MB，也必须立刻处理
用 SQL 查真实使用率：必须关联 type 字段做归一化计算
v$asm_diskgroup 视图里没自动帮你除冗余系数，直接算 (total_mb - free_mb)/total_mb*100 得出的百分比，在正常冗余下只有一半参考价值。
- 外部冗余（
EXTERN）：可用空间 ≈Total_MB，公式可直接用 - 正常冗余（
NORMAL）：理论最大可用 =Total_MB / 2，真实使用率应为(used_mb) / (total_mb/2) * 100 - 高冗余（
HIGH）：理论最大可用 =Total_MB / 3，对应分母要换成total_mb/3
推荐一句查全量的 SQL：
SELECT name, type, total_mb, free_mb,<br> ROUND((total_mb - free_mb) * 100 / total_mb, 1) AS reported_pct,<br> ROUND((total_mb - free_mb) * 100 /<br> CASE type WHEN 'NORMAL' THEN total_mb/2<br> WHEN 'HIGH' THEN total_mb/3<br> ELSE total_mb END, 1) AS real_pct<br>FROM v$asm_diskgroup;
警惕重新平衡（rebal）过程中的“瞬时空间黑洞”
看到 lsdg 里 Rebal 列是 Y，或查 v$asm_operation 发现状态为 REBAL，说明 ASM 正在搬数据——这时 Free_MB 数值会快速下跌，且不可逆回退。
- 添加/删除磁盘、调 AU 大小、改冗余级别都会触发 rebal
- rebal 不是“边读边写”，而是先在目标位置写满一份，再删旧数据；高峰期临时占用可达原数据量的 20%~30%
- 若磁盘组当前
Usable_file_MB＜ 预估 rebal 所需空间，操作会卡住并报错ORA-15032/ORA-15137
别漏掉元数据和 AU 对齐带来的“隐藏损耗”
ASM 每个磁盘组有固定开销：系统元数据区（约 0.5–1%）、分配单元（AU）向上取整、条带边界对齐——这些不会出现在 free_mb 里，但真实占着物理块。
- 比如一个 1MB 文件，在 4MB AU 的磁盘组中仍会占满 4MB
- 大量小文件场景下，
du命令（asmcmd du DATA/）比lsdg更反映实际占用 - 运行
asmcmd ls -l看单个文件大小 +ls -s看实际扇区占用，差值就是 AU 浪费量
真实容量永远比报表少一点，而且越细粒度操作，这个“少一点”越明显。
