rman在rac下无法直接restore/recover共享数据文件，必须异机单实例恢复：因rac的ocr、asm及集群机制与rman独占挂载要求冲突，需在同版本独立主机搭建单实例，用原备份+全量归档（含所有thread）还原控制文件（须先set dbid）、恢复数据库并导出数据。
rman 在 rac 下无法直接 restore/recover 共享数据文件到原集群 —— 必须走异机单实例恢复路径
RMAN restore database 在 RAC 中报 ORA-01102 或 ORA-01507 怎么办
这是最典型的误操作信号：你在 RAC 节点上执行 RESTORE DATABASE 或 RECOVER DATABASE，结果数据库起不来，或报“cannot mount database in EXCLUSIVE mode”（ORA-01102）或“database not mounted”（ORA-01507）。根本原因不是命令写错，而是 RAC 的共享存储 + 多实例并发机制与 RMAN 恢复流程冲突——RMAN 恢复过程默认要求数据库处于 NOMOUNT 或 MOUNT 独占状态，而 RAC 实例间无法协调这种独占挂载。
- 别在原 RAC 集群任何节点上尝试
STARTUP MOUNT后恢复；那只会卡死或触发 OCR 报错 - 哪怕你只启一个实例、其他实例全停，仍可能因 ASM diskgroup 未 dismount 或 voting disk 锁争用失败
- 真实可行的起点是：完全脱离 RAC 环境，在一台干净的 Linux 主机上装同版本 Oracle（如 12.1.0.2），不配集群软件，不启 CRS
为什么不能用 RMAN recover table 恢复 RAC 中误删的表
RECOVER TABLE 命令在 RAC 下直接失效，不是配置问题，是架构级不兼容。它底层依赖自动创建的辅助实例（auxiliary instance），而该实例必须是单机、非 ASM、本地文件系统 + 独立监听的常规数据库。RAC 的 OCR 注册、ASM 磁盘组挂载、集群心跳机制会直接阻止该辅助实例启动。
- 执行时大概率报
ORA-19566: exceeded limit of 0 corrupt blocks for file或静默失败 - 即使你手动指定
AUXILIARY DESTINATION，RMAN 仍试图在当前节点本地起库，而非真正隔离环境 - 对 PDB 内的表同样无效——必须连
CDB$ROOT才能调用该命令，但 RAC 的 CDB 启动模式本身就不满足辅助实例要求
异地恢复时 controlfile 和 DBID 不匹配导致 restore 失败
异机恢复第一步就卡在 RESTORE CONTROLFILE？十有八九是 SET DBID 没设，或设错了。RAC 的 v$database.dbid 是全局唯一值，但不同 RAC 实例查出来的 DBID 完全一致——你必须从任意一个在线节点查，例如：
SQL> SELECT dbid FROM v$database;
然后在 RMAN 连接后第一句就必须执行：
RMAN> SET DBID 1234567890;
- 漏掉这句，
RESTORE CONTROLFILE FROM 'xxx'会报RMAN-06023: no backup or copy of control file found，即使备份文件物理存在 - 控制文件必须从 RMAN 备份中还原，不能用
BACKUP CONTROLFILE TO TRACE生成的 SQL 脚本——trace 文件不含归档日志序列链，后续RECOVER DATABASE必然中断 - 确认备份片里真有控制文件：用
LIST BACKUP OF CONTROLFILE查，且确保该备份是在表空间删除前做的
recover database until time 卡住，提示 archived log not found
这几乎必然是归档日志没拷全。RAC 每个实例（thread）都独立生成归档，比如两节点 RAC 就有 thread 1 和 thread 2 两套归档序列。你只拷了 node1 的归档（/arch1/），却没拷 node2 的（/arch2/），RECOVER DATABASE UNTIL TIME 就会在读到 thread 2 的第一个缺失归档时挂住，报类似：
archived log for thread 2 with sequence 45678 not found
- 必须把所有 instance 的归档日志（含 thread 1/2/…）全部拷到目标机同一目录下，例如
/backup/arch/ - 在 RMAN 中注册：
CATALOG START WITH '/backup/arch/'; - 检查是否识别全：
LIST ARCHIVELOG ALL;应该看到所有 thread 的连续序列 - 如果某 thread 归档确实缺失，只能退回到该 thread 最后一个可用归档的时间点做不完全恢复，数据会有少量丢失
关键点常被忽略：RAC 异地恢复不是“把备份拷过去 run 一下”，而是重建一套时间点一致的只读副本；所有路径映射、DBID、归档完整性、参数文件中 db_file_name_convert 的 ASM 到本地路径转换，缺一不可。任何一步跳过验证，都会在 recover 阶段爆发。
