ASM磁盘掉线后不会自动踢出，而是标记为MISSING并触发快速镜像同步；若超时未恢复则彻底删除并启动重平衡。
ASM磁盘掉线后，RAC节点是否自动踢出该磁盘？
不会自动踢出，但会立即标记为 missing 状态，并触发 asm 的快速镜像同步（fast mirror resync）机制——前提是磁盘组启用了该特性且故障是临时性的（如线缆松动、hba卡瞬断）。若磁盘长时间不可达（默认 3.6 秒未响应，由 _asm_disk_repair_time 控制），asm 会将其从磁盘组中彻底删除，并启动完全重平衡（rebalance），从镜像副本读取并重建数据。
关键判断点：SELECT name, state, repair_timer FROM v$asm_disk WHERE group_number = X; 中 repair_timer > 0 表示仍在等待修复窗口内；若为 0 且状态是 OFFLINE 或 MISSING，说明已进入重建流程。
替换物理磁盘前，必须先在ASM中删除旧磁盘吗？
必须。不能直接拔盘再加新盘。ASM 不感知底层设备更换，必须显式执行 ALTER DISKGROUP ... DROP DISK（或 DROP DISK ... REBALANCE POWER n）来通知 ASM 释放该磁盘上的 Extent 并启动重分布。否则新磁盘加入后，ASM 会认为这是“重复路径”，报错 ORA-15032: not all alterations performed 或 ORA-15075: disk is already a member of diskgroup。
实操建议：
- 确认磁盘组冗余级别：
EXTERNAL冗余下无镜像，掉盘即丢数据，必须先恢复备份再操作 - 检查重平衡负载：
SELECT * FROM v$asm_operation;确保无进行中的 rebalance，否则 DROP 会被阻塞 - 使用
FORCE选项仅在磁盘已物理消失且无法 ONLINE 时使用：ALTER DISKGROUP dg1 DROP DISK 'ORCL:OLDISK' FORCE;
新加磁盘后，rebalance 操作卡住或极慢怎么办？
常见原因是默认的 POWER 值太低（默认 1），尤其在大容量磁盘组（>10TB）上，可能耗时数小时甚至冻结 I/O。更危险的是：RAC 环境中若一个节点发起 rebalance，其他节点的 ASM 实例会同步参与，但若某节点心跳异常或 CSSD 不稳，可能导致 v$asm_operation 显示 EXECUTING 却无进度。
应对措施：
- 手动指定更高
POWER（1–11）：ALTER DISKGROUP dg1 REBALANCE POWER 5;，注意 POWER 越高，I/O 和 CPU 开销越大，需避开业务高峰 - 检查
v$asm_client和v$css_history，确认所有 RAC 节点的 ASM 实例状态正常，无INTERMEDIATE或FAILED记录 - 避免在 rebalance 过程中修改同一磁盘组的其他属性（如添加/删除磁盘、调整 AU size），否则可能触发二次 rebalance 并中断当前流程
如何验证替换后数据完整性？
不能只看 v$asm_operation 完成和磁盘状态变为 ONLINE。ASM 不校验块内容一致性，仅保证 Extent 分布正确。真正风险在于：原磁盘故障时已有静默损坏（silent corruption），而镜像副本恰好也损坏（多副本同时损坏虽小概率但非零），此时 rebalance 只是把坏数据复制过去。
必须补做两件事：
- 运行
ASMCMD md_backup备份当前磁盘组元数据，便于后续比对 - 对关键数据库文件执行逻辑校验：
RMAN> VALIDATE DATABASE CHECK LOGICAL;（需开启DB_BLOCK_CHECKING=TRUE）或针对 ASM 文件用amdu工具抽样 dump 块头比对 checksum - 监控
v$asm_disk_iostat中新磁盘的read_errs/write_errs是否归零，非零值说明底层存储仍有硬件问题
最易被忽略的是：RAC 中 OCR/Voting Disk 所在磁盘组（通常是 +OCR）必须单独验证，其损坏会导致集群无法启动，且不能用普通 RMAN 校验，得依赖 ocrcheck -local 和 crsctl query css votedisk。
