磁盘组真实空间瓶颈需先查v$asm_diskgroup中pct_free是否接近0且type为external/normal；high类型必须成对加盘，否则报ora-15036；rac加盘前须确保各节点os层设备路径、权限、major/minor号、udev规则或asmlib扫描完全一致；asm层需alter system scan disks后确认header_status为member/candidate；加盘命令路径须严格匹配v$asm_disk.path并指定name；rebalance未完成前扩表空间仍会报ora-01653/01654。
确认磁盘组真实空间瓶颈与冗余类型
表空间报 ORA-01653 或 ORA-01654 时，别急着加盘——先查是不是真没空间。执行：SELECT name, type, total_mb, free_mb, round(free_mb/total_mb*100,1) pct_free FROM v$asm_diskgroup;
若 pct_free 接近 0，且 type 是 EXTERNAL 或 NORMAL，才适合单盘扩容；HIGH 类型必须成对添加，否则 ALTER DISKGROUP ... ADD DISK 直接报 ORA-15036。
注意：free_mb 不为 0，但 ALLOCATED_AREA 接近 TOTAL_MB 时，ASM AU 碎片也可能导致无法分配新单元，此时加盘仍是有效解法。
确保新磁盘在所有RAC节点OS层可见且权限一致
RAC 加盘失败 90% 卡在这步：节点 1 能看到，节点 2 的 v$asm_disk 返回空，最终 ADD DISK 报 ORA-15075（“disk(s) are not visible cluster-wide”）。
每个节点都必须验证以下四点完全一致：
-
ls -l /dev/mapper/asm-data9（或你的 UDEV 路径）中属主是grid:asmadmin - 权限是
brw-rw---- - major/minor 号（如
8, 16）跨节点完全相同 - UDEV 场景下，
/etc/udev/rules.d/99-oracle-asm.rules内容一致，并执行udevadm trigger && udevadm settle；ASMLib 场景下，每个节点单独运行oracleasm scandisks
asmcmd lsdsk | grep -i new必须全部返回结果，才算 OS 层真正就绪。
让ASM实例识别新磁盘并执行ADD DISK
OS 层可见 ≠ ASM 层可见。每个节点分别以 grid 用户连接：sqlplus / as sysasm
然后运行：SELECT path, header_status FROM v$asm_disk WHERE path LIKE '%asm-data9%';
若返回为空，说明 ASM 还没扫描到，立即执行：ALTER SYSTEM SCAN DISKS;
再查，header_status 必须是 MEMBER 或 CANDIDATE 才可加盘；若为 FORMER，说明曾加入又被删过，需谨慎评估是否要 FORCE 清理头信息。
加盘命令中路径必须与 v$asm_disk.path 显示的**完全一致**（区分大小写、含转义符），例如：ALTER DISKGROUP DATADG ADD DISK '/dev/mapper/asm-data9' NAME DATADG_004 REBALANCE POWER 2;
务必带 NAME 子句，避免后续诊断时出现 DATA_0001 这类不可读编号。
监控REBALANCE过程并等待完成后再扩展表空间
REBALANCE 是真正在后台移动数据的阶段，不是“加完就生效”。它持续占用 I/O，设高了不是更快，而是可能拖垮 LGWR 或归档写入。
-
POWER 1：适合生产高峰期，耗时数小时以上，业务延迟几乎无感 -
POWER 5~11：仅限低峰窗口期，必须轮询v$asm_operation查看EST_MINUTES和STATE
ADD DISK 后，不要立刻去扩表空间。先确认：SELECT * FROM v$asm_operation;返回为空，且
v$asm_diskgroup.free_mb 已明显上升，才算重平衡完成。此时再执行
ALTER TABLESPACE users ADD DATAFILE ...，否则仍会报空间不足错误。
