ASM磁盘组空间不足需从存储层解决，先查v$asm_diskgroup确认free_mb和分配碎片，再检查OS层磁盘可见性与权限一致性，最后执行ALTER DISKGROUP ADD DISK并等待重平衡完成。
ASM磁盘组空间不足，不是表空间或数据文件的问题，而是底层存储层已无可用分配单元（AU）——直接 ALTER TABLESPACE ADD DATAFILE 会报 ORA-15041 或 ORA-01653，此时必须从 ASM 层入手。
先确认是不是真没空间，还是只是碎片卡住
别急着加盘或迁移，先看真实瓶颈：
- 执行
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，才适合扩容 - 查
ALLOCATED_AREA：即使free_mb > 0，若ALLOCATED_AREA / TOTAL_MB接近 100%，说明 AU 分配碎片严重，ADD DISK仍是最有效解法 - 注意冗余类型：
HIGH类型磁盘组必须成对添加磁盘，否则ALTER DISKGROUP ... ADD DISK直接报ORA-15036
RAC 加盘失败，90% 卡在 OS 层不一致
ORA-15075: disk(s) are not visible cluster-wide 不是 ASM 问题，是节点间磁盘状态不统一：
- 每个节点都运行
ls -l /dev/mapper/asm-data9（替换成你的 udev 路径）：属主必须是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才算成功识别 -
ALTER DISKGROUP DATADG ADD DISK中的PATH必须与v$asm_disk.path中显示的**完全一致**（大小写、斜杠、转义符都不能错） - 加盘后等重平衡完成（查
v$asm_operation），再动表空间；否则ALTER TABLESPACE ... ADD DATAFILE仍可能失败
无法加盘时，临时在线腾空间的实操路径
硬件不可扩、窗口不允许停机？优先清理高占用非核心文件：
- 查哪些文件占大头：
./asmdu.sh +DATA/MESDB（脚本见知识库），重点关注ONLINELOG/和TEMPFILE/目录 - 临时表空间可在线重建：
CREATE TEMPORARY TABLESPACE temp2 TEMPFILE '+DATA1' SIZE 2G;→ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp2;→DROP TABLESPACE temp INCLUDING CONTENTS AND DATAFILES; - 在线重做日志可迁移（需切换日志+归档）：
ALTER DATABASE ADD LOGFILE THREAD 1 '+DATA1' SIZE 512M;→ALTER SYSTEM SWITCH LOGFILE;→ALTER DATABASE DROP LOGFILE GROUP N; - 归档日志路径在 FRA 磁盘组？用
RMAN清理：DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-3';，别手动删ASMCMD下的文件
加盘和迁移都是手段，关键在判断哪一层真正堵住了——v$asm_diskgroup 的 free_mb 是假象，v$asm_disk 的 header_status 和 v$asm_operation 的进度才是真实信号。
