在线扩展oracle rac的asm磁盘组可行，但必须严格完成节点设备一致性检查、asm扫盘确认及冗余校验，否则将触发ora-15032或disk_repair_time超时，导致磁盘组异常。
在线扩展 oracle rac 的 asm 磁盘组空间完全可行，但“不需停机”不等于“无需验证”——跳过节点一致性检查、asm 扫盘确认或冗余策略校验，alter diskgroup ... add disk 会直接报 ora-15032 或卡在 disk_repair_time 超时，最终导致磁盘组异常甚至无法 mount。
所有 RAC 节点 OS 层设备必须完全一致可见
这是最常被跳过的前置动作，也是后续失败的根源。不是“能 ls 出来就行”，而是路径、属主、权限、major/minor 号四者全部对齐。
- 在每个节点执行：
ls -l /dev/mapper/asm-diskm（UDEV 场景）或oracleasm listdisks（ASMLib），确认设备存在且属主为grid:asmadmin、权限为brw-rw---- - 比对 major/minor 号：输出中第 5–6 列数字（如
8, 16）必须跨节点完全相同；不一致说明多路径未收敛或 udev 规则未生效 - UDEV 场景下，检查
/etc/udev/rules.d/99-oracle-asm.rules在所有节点内容一致，并执行：udevadm trigger && udevadm settle - ASMLib 场景下，每个节点都必须单独运行：
oracleasm scandisks，不能只在节点 1 执行
ASM 实例必须已识别新磁盘且状态为 CANDIDATE
v$asm_disk 中看不到磁盘，ADD DISK 必然失败。OS 层可见 ≠ ASM 层可见——这是 RAC 环境下最典型的“半边生效”问题。
- 每个节点分别用
sqlplus / as sysasm连接 ASM 实例，运行：SELECT path, header_status FROM v$asm_disk WHERE path LIKE '%asm-diskm%'; - 返回为空？说明 ASM 还没扫描到，立即执行：
ALTER SYSTEM SCAN DISKS;（注意：该命令需在每个节点单独执行） - 返回
header_status = 'CANDIDATE'才可加盘；若为'FORMER'，说明曾加入又被删过，需先FORCE清理头信息（高风险，慎用） - 验证全局识别：在每个节点运行
asmcmd lsdsk -k，输出应完全一致
ADD DISK 语法与 REBALANCE POWER 设置要匹配业务节奏
REBALANCE 是真正在后台干活的阶段，它持续占用 I/O。设高了不是更快，而是可能拖垮 LGWR、归档写入或引发 SQL 延迟飙升。
- 基础命令必须带
NAME子句：ALTER DISKGROUP DATA ADD DISK '/dev/mapper/asm-diskm' NAME DATA_0004 REBALANCE POWER 2;（不命名会导致后续诊断困难） -
POWER 1：适合生产高峰期，rebalance 持续数小时以上，但业务延迟几乎无感 -
POWER 5~11：仅限低峰窗口期使用，务必轮询v$asm_operation监控EST_MINUTES和EST_RATE，避免 I/O 饱和 - 禁用
REBALANCE WAIT：它会阻塞当前会话，生产环境应让 rebalance 异步运行
表空间不会自动扩容，必须手动添加数据文件
磁盘组 free_mb 上涨了，不代表任何表空间能用上这空间。ASM 只管物理块，不管逻辑结构——这点极易被忽略。
- 执行：
ALTER TABLESPACE ODS ADD DATAFILE '+DATA' SIZE 10G AUTOEXTEND ON NEXT 1G MAXSIZE UNLIMITED; -
'+DATA'必须与v$asm_diskgroup.name完全一致（大小写敏感），写成'+data'或'DATA'会报错 - Smallfile 表空间：支持多数据文件，用
ADD DATAFILE - Bigfile 表空间：仅允许一个数据文件，此时只能
ALTER DATABASE DATAFILE '+DATA/ods.256.12345' RESIZE 50G;
整个过程看似线性，但 RAC 下真正的复杂点在于“时间差”：OS 层设备识别有延迟、ASM 扫盘有延迟、rebalance 进度在各节点不一致。别依赖“在一个节点做完就完了”，每个验证步骤都要在所有节点独立完成，否则你看到的只是局部正常。
