在线扩容需严格验证：节点设备路径、属主、权限、major/minor号必须完全一致；v$asm_disk须显示header_status='CANDIDATE'；ADD DISK须带NAME并匹配REBALANCE POWER，且disk_repair_time需适配冗余策略。
可以在线扩容，但“无需停机”不等于“跳过验证”——漏掉节点设备一致性检查、asm扫盘确认或冗余策略校验，alter diskgroup ... add disk 会直接报 ora-15032 或卡在 disk_repair_time 超时，最终磁盘组无法 mount。
所有 RAC 节点 OS 层设备必须完全一致可见
这不是“能 ls 出来就行”，而是路径、属主、权限、major/minor 号四者全部对齐。常见错误：一个节点看到 /dev/mapper/asm-diskm 权限是 brw-rw----，另一个节点却是 brw-------；或者 ls -l 输出第 5–6 列（如 8, 16）跨节点不一致。
- UDEV 场景下，在每个节点执行：
ls -l /dev/mapper/asm-diskm，确认属主为grid:asmadmin、权限为brw-rw---- - 比对
major/minor号：输出中第 5–6 列数字必须完全相同；不一致说明多路径未收敛或 udev 规则未生效 - 检查
/etc/udev/rules.d/99-oracle-asm.rules在所有节点内容一致，然后执行：udevadm trigger && udevadm settle - ASMLib 场景下，每个节点都必须单独运行：
oracleasm scandisks（不能只在节点 1 执行）
v$asm_disk 中看不到新磁盘？说明 ASM 还没识别到
OS 层可见 ≠ ASM 层可见——这是 RAC 环境下最典型的“半边生效”问题。如果 v$asm_disk 里查不到目标路径，ADD DISK 必然失败。
- 每个节点分别用
sqlplus / as sysasm连接 ASM 实例，运行：SELECT path, header_status FROM v$asm_disk WHERE path LIKE '%asm-diskm%'; - 返回为空？立即在该节点执行：
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 - 加盘完成后，建议将
POWER降回 1：ALTER DISKGROUP DATA REBALANCE POWER 1;
最容易被忽略的是：disk_repair_time 默认 3.6 小时，如果 rebalance 时间超过这个值，且期间有磁盘异常，ASM 会直接 drop 该盘——所以加盘前务必确认当前磁盘组冗余策略是否允许容忍临时不平衡，尤其是 EXTERNAL 冗余磁盘组，没有镜像容错能力。
