RAC环境下ASM加盘需确保四要素一致、header_status为CANDIDATE、ADD DISK带NAME且REBALANCE POWER合理、disk_repair_time适配冗余策略，否则易触发ORA-15032/15027或磁盘组无法MOUNT。
ALTER DISKGROUP 加盘操作本身是在线的，但“能执行”不等于“会成功”——RAC环境下跳过节点一致性校验、ASM扫盘确认或冗余策略检查，大概率触发 ORA-15032 + ORA-15027，甚至导致磁盘组无法 MOUNT。
所有RAC节点OS设备路径、属主、权限、major/minor号必须完全一致
这不是“ls /dev/asm-diskm 能看到就行”，而是四要素缺一不可：
- 路径（如
/dev/mapper/asm-diskm）必须相同，大小写和符号（如斜杠结尾）都要一致 - 属主必须为
grid:asmadmin，不能是root:root或oracle:oinstall - 权限必须是
brw-rw----（注意开头的b表示块设备） - major/minor号必须跨节点完全相同：执行
ls -l /dev/mapper/asm-diskm，看第5–6列数字（如253, 4），任一节点不同，说明多路径未收敛或udev规则未生效
UDEV场景下，检查 /etc/udev/rules.d/99-oracle-asm.rules 在所有节点内容是否一字不差；然后在每个节点分别运行：udevadm control --reload、udevadm trigger --type=devices、udevadm settle。
v$asm_disk 中 header_status 必须为 CANDIDATE 才能加盘
OS层可见 ≠ ASM层可见。常见现象是节点1查 v$asm_disk 有记录，节点2为空——这就是典型的“半边生效”，后续 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'或'PROVISIONED'才可安全加盘；若为'FORMER'，说明曾加入又被删过，需先清理头信息（高风险，慎用） - 验证全局识别：每个节点运行
asmcmd lsdsk -k，输出必须完全一致
ADD DISK 必须带 NAME 子句且 REBALANCE POWER 要匹配业务节奏
REBALANCE 是真正在后台移动数据的阶段，持续占用 I/O。设高了不是更快，而是可能拖垮 LGWR、归档写入或引发 SQL 延迟飙升。
- 基础语法必须含
NAME：ALTER DISKGROUP DATA ADD DISK '/dev/mapper/asm-diskm' NAME DATA_0004 REBALANCE POWER 2;；不命名会导致后续诊断困难，DROP或故障排查时只能靠编号（如DATA_0001）区分 -
POWER 1：适合生产高峰期，rebalance 持续数小时以上，但业务延迟几乎无感 -
POWER 5~11：仅限低峰窗口期使用，务必轮询v$asm_operation监控EST_MINUTES和EST_RATE - 加盘完成后，建议立即将
POWER降回 1：ALTER DISKGROUP DATA REBALANCE POWER 1;
disk_repair_time 必须适配冗余策略，否则会超时失败
这个参数不是加盘时设置的，而是磁盘组创建时就定死的，但扩容前必须确认它是否仍合理。例如 NORMAL 冗余下默认值为 3.6 小时，若新盘因网络抖动短暂不可见，又没及时恢复，就会触发自动 DROP 并报 disk_repair_time 超时错误。
- 查当前值：
SELECT name, disk_repair_time FROM v$asm_diskgroup WHERE name = 'DATA'; -
EXTERNAL冗余可设为0H（即禁用修复）；NORMAL建议不低于 2 小时；HIGH需成对添加，且disk_repair_time应留足冗余窗口 - 修改需在磁盘组
MOUNTED状态下执行：ALTER DISKGROUP DATA SET ATTRIBUTE 'disk_repair_time' = '4.5H';
最易被忽略的是：disk_repair_time 不是“越长越好”，它会影响 ASM 故障切换决策逻辑；而 REBALANCE POWER 的实际影响远大于文档描述——尤其在混合读写负载下，I/O 饱和点常出现在 POWER > 3 时。
