先查asm磁盘组真实状态：select name, state, total_mb, free_mb from v$asm_diskgroup;，若state为mounted则问题不在磁盘组本身；仅degraded或offline才需先修复asm层，否则rman restore会因路径不可用而报ora-15012或ora-01157。
确认asm磁盘组是否真的degraded或offline
别一看到数据库启不来就认定是磁盘组坏了。先连asm实例查真实状态：sqlplus / as sysasm，然后跑select name, state, total_mb, free_mb from v$asm_diskgroup;。如果state是mounted，说明磁盘组本身还活着，问题可能出在单个数据文件或控制文件路径上；只有degraded或offline才表明底层i/o异常已传导上来。误判会导致后续所有rman命令报ora-15012或ora-01157。
修复ASM层前不能直接RMAN RESTORE
ASM磁盘组处于DEGRADED时，RMAN根本找不到可用路径去写还原文件——它会卡在RESTORE DATAFILE阶段并报ORA-15012: ASM disk does not exist。必须先让ASM恢复健康：
- 确认冗余策略：只有
NORMAL或HIGH冗余才能安全ALTER DISKGROUP ... DROP DISK；EXTERNAL冗余下丢盘=直接丢数据 - 执行
ALTER DISKGROUP DG_NAME DROP DISK FAIL_DISK_NAME踢掉故障盘（注意不是FORCE） - 用
ALTER DISKGROUP DG_NAME ADD DISK '/dev/oracleasm/disks/DISK_NEW'加入新盘，触发REBALANCE - 盯住
v$asm_operation，等STATE = COMPLETED后再进RMAN
跳过这步强行RMAN，可能把剩余好盘拖进不稳定状态，甚至引发二次离线。
RMAN RESTORE时必须显式SET NEWNAME并SWITCH
即使ASM磁盘组修好了，RMAN还原出来的文件名（如+DATA/orcl/datafile/users.256.123456789）和控制文件里记录的路径（如/u01/oradata/orcl/users01.dbf）不一致，RECOVER阶段立刻报ORA-01122和ORA-01110。关键动作是：
- 先查目标文件当前ASM别名：
SELECT name FROM v$datafile WHERE file# = 4; - RMAN中执行
SET NEWNAME FOR DATAFILE 4 TO '+DATA';（不是TO '+DATA/orcl/datafile/users.256.123456789'） -
RESTORE TABLESPACE users;完成后，必须SWITCH DATAFILE ALL;同步控制文件记录 - 漏掉
SWITCH是ALTER DATABASE DATAFILE 4 ONLINE失败的最常见原因
归档日志链断裂会导致RECOVER中断
物理磁盘损坏常连带毁掉归档路径——尤其当LOG_ARCHIVE_DEST_1指向坏盘。RMAN能成功RESTORE，但RECOVER卡在第一个缺失归档，报ORA-00308或ORA-19505。必须人工验证：
- 从备份集获取最小SCN：
LIST BACKUP OF DATABASE;看COMPLETION TIME对应SCN - 运行
LIST ARCHIVELOG FROM SCN <min_scn>;</min_scn>，确认输出包含连续SEQUENCE# - 若缺档，检查
DB_RECOVERY_FILE_DEST或LOG_ARCHIVE_DEST_n是否挂载、空间是否足够、权限是否为oracle:oinstall
OCR或votedisk所在的磁盘组若也受损，得先走ocrconfig -restore流程，否则集群资源起不来，RMAN连不上目标库——这点容易被忽略。
