表空间无法扩展的根本原因是底层ASM磁盘组空间不足，须先扩容磁盘组；RAC加盘失败主因是磁盘未在所有节点OS层可见且权限一致，需逐节点验证路径、权限、扫描及ASM识别状态，并等待重平衡完成后再扩展表空间。
表空间无法扩展，根本原因不是表空间本身，而是它所在的asm磁盘组已无可用空间。直接操作表空间（如alter tablespace ... add datafile）会报错 ora-01653 或 ora-01654，此时必须先扩容底层asm磁盘组——而在rac中加盘失败，90%是因为磁盘未在所有节点上真正就绪。
确认磁盘组真实空间瓶颈与冗余类型
别急着加盘，先验证是不是真没空间、以及能否单盘扩容：
- 执行
SELECT name, type, total_mb, free_mb, round(free_mb/total_mb*100,1) pct_free FROM v$asm_diskgroup;—— 若pct_free接近 0，且type是NORMAL或EXTERNAL，才适合加盘；HIGH类型必须成对添加，否则ALTER DISKGROUP ... ADD DISK直接报ORA-15036 -
SELECT name, redundancy FROM v$asm_diskgroup WHERE name = 'DATADG';必须明确冗余策略，避免后续误操作 - 注意：
free_mb不为 0 但ALLOCATED_AREA接近TOTAL_MB时，也可能因 ASM allocation unit 碎片导致无法分配新 AU，此时加盘仍是有效解法
确保新磁盘在所有RAC节点OS层可见且权限一致
RAC加盘最常卡在这一步——节点1能看到，节点2查 v$asm_disk 返回空，最终 ADD DISK 报 ORA-15075：“disk(s) are not visible cluster-wide”。
- 在每个节点用
ls -l /dev/mapper/asm-data9（或你的UDEV SYMLINK路径）检查：属主必须是grid:asmadmin，权限必须是brw-rw----，major/minor 号需跨节点完全一致 - 若用 ASMLib，所有节点都必须执行
oracleasm scandisks；若用 UDEV，所有节点都要跑udevadm trigger --subsystem-match=block+udevadm settle - 别信“扫过一次就全好了”。执行完后，每个节点单独运行
asmcmd lsdsk | grep -i new，必须全部返回结果
让ASM实例识别新磁盘并执行ADD DISK
即使OS层可见，ASM 实例默认不会自动加载新磁盘路径，必须显式触发扫描。
- 每个节点分别以
grid用户执行：sqlplus / as sysasm→ALTER SYSTEM SCAN DISKS; - 立即查
SELECT path, header_status FROM v$asm_disk WHERE path LIKE '%asm-data9%';，返回MEMBER或CANDIDATE才算识别成功；若仍为空，说明扫描失败或路径写错（注意大小写、转义符） - 执行加盘命令时，
PATH必须与v$asm_disk.path中显示的**完全一致**：ALTER DISKGROUP DATADG ADD DISK '/dev/mapper/asm-data9' NAME 'DATA_NEW9' REBALANCE POWER 3; - 务必带
NAME子句。不命名会导致后续诊断时磁盘显示为DATA_0001这类编号名，极易混淆，尤其在多盘同时操作时
控制REBALANCE强度与验证完成状态
加盘后自动触发重平衡，但这个过程会持续占用I/O，不是“加完就扩完”。
- 用
SELECT * FROM v$asm_operation;监控进度，STATE为EXECUTING表示正在进行，POWER值越高越快但IO压力越大；生产高峰期建议显式指定POWER 1，低峰期可设POWER 5 - 不要省略
WAIT（如REBALANCE POWER 3 WAIT），否则命令返回即结束，后台任务可能堆积，影响后续操作判断 - 验证是否生效：查
v$asm_diskgroup的total_mb是否增加；再查v$asm_disk中新盘的mount_status应为MOUNTED，state为NORMAL
实际扩容后，表空间才能继续扩展。但要注意：重平衡未完成前，ALTER TABLESPACE ... ADD DATAFILE 虽然能执行成功，但新数据文件实际仍受限于原磁盘组的物理空间上限——所以必须等 v$asm_operation 清空后再操作表空间。
