如何监控Oracle ASM磁盘组的空间利用率与再平衡进度？-Oracle-PHP中文网

真实使用率需按冗余类型归一化计算：external用total_mb为分母，normal用total_mb/2，high用total_mb/3；直接用free_mb算出的百分比在normal下仅具一半参考价值。

asmcmd lsdg 显示的 free_mb 不能直接当剩余空间用，尤其在 normal 或 high 冗余下，它只是逻辑可写量，不是物理空闲量。真实可用上限是 usable_file_mb，低于 req_mir_free_mb 就会拒绝写入。

怎么看真实空间使用率（别信 Free_MB）

直接查 v$asm_diskgroup 视图时，(total_mb - free_mb) / total_mb * 100 算出来的百分比，在 NORMAL 冗余下只有一半参考价值——因为镜像副本占着物理空间，但没被算进 free_mb 扣减逻辑。

EXTERN 冗余：可用空间 ≈ total_mb，公式可直接用
NORMAL 冗余：理论最大可用 = total_mb / 2，真实使用率应为 (total_mb - free_mb) * 100 / (total_mb/2)
HIGH 冗余：分母换成 total_mb / 3

推荐一句查全量的 SQL：

SELECT name, type, total_mb, free_mb,
  ROUND((total_mb - free_mb) * 100 / total_mb, 1) AS reported_pct,
  ROUND((total_mb - free_mb) * 100 /
    CASE type WHEN 'NORMAL' THEN total_mb/2
              WHEN 'HIGH'   THEN total_mb/3
              ELSE total_mb END, 1) AS real_pct
FROM v$asm_diskgroup;

怎么判断是否正在 rebal（再平衡）及影响

看到 asmcmd lsdg 输出里 Rebal 列是 Y，或查 v$asm_operation 发现 STATE = 'REBAL'，说明 ASM 正在搬数据。这不是“边读边写”，而是先在目标位置写满一份，再删旧数据，高峰期临时占用可达原数据量的 20%~30%。

QuantOracle

63个确定性量化金融计算器 + 10个通过MCP的复合工作流。期权定价、Greeks、奇异衍生品、风险指标、投资组合优化……

下载

添加/删除磁盘、调 AU 大小、改冗余级别都会触发 rebal
如果当前 Usable_file_MB 小于预估 rebal 所需空间，操作会卡住并报错 ORA-15032 / ORA-15137
v$asm_operation 中的 POWER 和 EST_MINUTES 只是粗略估算，实际时间受 I/O 压力、磁盘负载、ASM_POWER_LIMIT 设置影响很大
rebal 过程中 Free_MB 会快速下跌，且不可逆回退，此时看它没意义

怎么发现隐藏空间损耗（AU 对齐和元数据）

ASM 每个磁盘组有固定开销：系统元数据区（约 0.5–1%）、分配单元（AU）向上取整、条带边界对齐——这些不体现在 free_mb 里，但真实占着物理块。

一个 1MB 文件，在 4MB AU 的磁盘组中仍会占满 4MB
大量小文件场景下，asmcmd du DATA/ 比 lsdg 更反映实际占用
用 asmcmd ls -l +DATA/ORCL/DATAFILE/system.256.987654321 看逻辑大小，再用 asmcmd ls -s 看实际扇区占用，差值就是 AU 浪费量
元数据开销在磁盘组刚创建时就已预留，无法回收，大磁盘组相对影响小，小磁盘组（比如 OCR）要特别留意

真正危险的不是 Free_MB 掉到零，而是 Usable_file_MB 贴近 Req_mir_free_MB；rebal 期间所有常规空间指标都失真；AU 浪费和元数据开销不会报错，但会在你加新表空间时突然“没空间了”。