单节点恢复本身不影响业务，前提是其他节点正常且连接池配置正确；常见中断原因是应用直连单节点sid而非scan+服务名，导致节点宕机后无法自动重路由。
单节点恢复本身不影响业务——前提是其他节点正常运行且应用连接池配置正确。 RAC 的设计目标就是允许单节点故障或维护，但实际操作中仍常因配置疏漏导致业务中断。关键不在“能不能”，而在“怎么确保不被误切”。
为什么业务会中断？不是RAC不行，是连接没配对
常见错误是应用直连某个 SID（如 orcl1），而非使用 SCAN 地址 + 服务名。一旦该节点停机，连接直接失败，连接池无法自动重路由。
- 检查应用数据源配置：必须用
jdbc:oracle:thin:@scan-ip:1521/service_name，不能写@node1-ip:1521/orcl1 - 确认服务名已启用负载均衡和故障转移：
srvctl config service -d orcl中应含failovertype=SESSION和clbgoal=SHORT - 验证 TNSNAMES.ora 或 wallet 中的连接描述符是否包含所有实例别名，并启用
RETRY_DELAY=1和CONNECT_TIMEOUT=10
恢复前必须停掉该节点上的监听和服务，而非整个实例
直接 srvctl stop instance -d orcl -i orcl1 会触发集群重新平衡，可能引发短暂全局等待；更稳妥的做法是先隔离该节点的流量入口。
- 执行
srvctl stop listener -n node1，断开外部连接入口，但保留实例和后台进程运行（便于快速回滚） - 若需真正停实例，用
srvctl stop instance -d orcl -i orcl1 -f（-f强制，避免等待 CRS 协调） - 切勿在节点上手动
sqlplus / as sysdba执行shutdown immediate—— 这会绕过 CRS 管理，导致 OCR 状态不一致，后续srvctl start可能失败
RMAN 恢复时别碰控制文件和归档路径共享性
单节点恢复通常只涉及数据文件还原或不完全恢复，但若误操作控制文件或归档位置，会影响所有节点。
- 恢复前确认当前节点的
ORACLE_SID正确（如orcl1），且 RMAN 连接方式为rman target /（非rman target sys/pass@orcl1），否则可能读错控制文件快照 - 不要在 run 块中执行
restore controlfile—— 控制文件是共享的，改一个节点就等于改全集群；除非整库恢复，否则跳过这步 - 归档日志路径必须指向共享存储（如
+FRA/orcl/ARCHIVELOG），不能指定本地路径；否则其他节点无法访问归档，recover database会卡住
OPEN RESETLOGS 是雷区，单节点绝不允许执行
alter database open resetlogs 会重置全库 SCN 并清空所有线程的在线日志，RAC 下必须所有实例同步执行，否则节点间 SCN 分裂，轻则 ORA-600，重则数据库挂起。
- 单节点恢复后若需 open，只能用
alter database open（非 resetlogs），前提是控制文件未重建、归档连续、且该节点 thread 已启用 - 如果之前做了 restore controlfile，必须先
alter database mount，再recover database，最后alter database open—— 任何 resetlogs 操作都意味着你要重做整个 RAC 恢复流程 - 检查 thread 状态：
select thread#, status, enabled from v$thread;，确保待恢复节点的 thread 为ENABLED且STATUS = OPEN
最易被忽略的是服务状态与连接池超时参数的协同——哪怕 RAC 集群本身稳如磐石，一个 connect_timeout=30s 而应用重试间隔设为 5s 的配置，就足以让恢复期间的短暂不可用被放大成大面积超时。动手前，先看连接链路，再动数据库。
