ALTER DISKGROUP加盘需先确认磁盘为CANDIDATE状态、asm_diskstring覆盖路径、权限正确；再执行ADD DISK并合理设置REBALANCE POWER；最后手动扩展表空间数据文件，全程在线但须严防OCR/Voting盘异常。
ALTER DISKGROUP 是核心操作，但直接加盘不等于表空间立刻可用——必须先让 ASM 磁盘组有空间，再让表空间能用上这个空间。整个过程可在线完成，无需停库，但关键路径上几个动作顺序错不得、参数设不对就容易卡住或触发意外 rebalance。
确认磁盘组还有“可添加的磁盘”且 ASM 能发现它
新磁盘没被 v$asm_disk 列出来，后续一切操作都无效。常见卡点不是存储没挂，而是操作系统层识别不一致或权限未到位：
- 在两个 RAC 节点都执行
ls -l /dev/asm*，确保符号链接存在且属主是grid:asmadmin - 用
sqlplus / as sysasm连接后查：SELECT path, header_status FROM v$asm_disk WHERE header_status IN ('CANDIDATE', 'FORMER');——只有CANDIDATE才能直接加；如果是FORMER，说明之前加过又删了，得先FORCE清理头信息（风险操作，慎用） - 检查
asm_diskstring参数是否覆盖新盘路径：SHOW PARAMETER asm_diskstring；若用 udev 绑定，值通常是'/dev/asm*'；若用 multipath，得是'/dev/mapper/asm-*'或具体 dm 设备路径
向磁盘组 ADD DISK 时 POWER_LIMIT 和 REBALANCE 的取舍
加盘命令本身简单：ALTER DISKGROUP DATA ADD DISK '/dev/asm-diskm' REBALANCE POWER 2;，但 POWER 值设高 ≠ 更快，反而可能拖垮 I/O：
-
POWER 1：最保守，rebalance 持续数小时甚至更久，但业务 SQL 延迟几乎无感 -
POWER 5~11（Oracle 11g 默认上限）：适合空闲窗口期，但需监控v$asm_operation中的EST_MINUTES和EST_RATE，避免因 I/O 饱和导致归档写入慢、LGWR 等待升高 - 别用
REBALANCE WAIT：它会阻塞当前会话，而生产环境应让命令异步执行，用轮询v$asm_operation判断进度
表空间扩容不是“自动跟上”的，得手动加数据文件
磁盘组 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表空间只能有一个数据文件，此时只能RESIZE原有文件 - 加完立即查
dba_data_files，确认STATUS是AVAILABLE，不是UNAVAILABLE（后者常因权限或路径解析失败）
最容易被忽略的验证点：OCR/Voting 盘是否意外受影响
所有操作都在 DATA 磁盘组，但 RAC 环境下误操作可能波及集群稳定性：
- 加盘前用
crsctl check cluster -all确保所有节点集群资源正常；加盘后至少等v$asm_operation返回 0 行，再跑一次检查 - 特别留意
OCR磁盘组的Voting_files列是否仍为Y：SELECT name, voting_files FROM v$asm_diskgroup WHERE name = 'OCR';——如果变成N，说明 OCR 磁盘组异常，集群可能降级 - 别在 rebalance 过程中重启任何节点，哪怕只是
crsctl stop crs，都可能导致 disk header 损坏，恢复成本远高于等待几小时 rebalance
