Oracle 19c单实例迁RAC前必须确保GI与DB补丁集完全一致，包括RU版本；控制文件须重写至ASM路径；undo表空间、redo线程需按节点独立配置；监听必须指向SCAN地址。
迁移前必须确认的版本与补丁一致性
oracle 19c 单实例迁移到 rac，最常卡在 ora-01122、ora-01219 或 open resetlogs 失败——根本原因几乎全是版本不一致。不是“大版本相同就行”，而是 19.3.0.0.0 和 19.3.0.4.0 之间不能直接恢复，哪怕只差一个 ru（release update）。
- 用
opatch lsinventory在源库和所有 RAC 节点上分别检查，确保 GI 和 DB 的补丁集完全一致 - 若目标 RAC 是全新安装但未打最新 RU，先在所有节点执行
opatch apply，再启动 ASM 实例 - 特别注意：RAC 中每个节点的
ORACLE_HOME必须指向同一份已打补丁的二进制目录，不能各装各的
RMAN 异机恢复时 controlfile 路径必须重写
RMAN restore controlfile 默认会按源库路径还原，而 RAC 的控制文件必须放在 ASM 磁盘组里（如 +DATA），否则 alter database mount 直接报错 ORA-00205。
- 不要依赖
backup current controlfile原样恢复；先用restore controlfile to '/tmp/control01.ctl'拉到本地临时路径 - 再用
sqlplus / as sysdba启动到nomount，执行create controlfile reuse set database 'ORCL' ...，显式指定LOGFILE '+DATA/ORCL/ONLINELOG/group_1.256.12345'这类 ASM 路径 - 如果用了多租户（CDB/PDB），
create controlfile语句中必须包含ENABLE PLUGGABLE DATABASE，否则后续无法 open PDB
undo 表空间和 redo 线程不能复用单实例配置
单实例只有一个 undo 表空间和一组 redo 日志；RAC 至少需要两个线程（每个节点一个），且每个节点需独立的 undo 表空间。硬套原参数会导致实例启动失败或 CRS 报 ORA-01157。
- 迁移后首次启动前，修改 pfile 中：
undo_tablespace='UNDOTBS1'（节点1）、undo_tablespace='UNDOTBS2'（节点2），并确保这两个表空间已在 ASM 中创建 -
thread=1和thread=2必须分别在两个节点的 pfile 中显式设置，不能留空 - redo 日志组需按线程分配：线程 1 的日志组全部在
+DATA，线程 2 的全部在+FRA（或同组但不同成员），避免争用 - 别忘了用
srvctl add database -d ORCL -o $ORACLE_HOME注册数据库后，再用srvctl add instance分别添加两个实例
数据泵导入时 DESTROY=Y 不解决 schema 冲突
用 impdp 全库导入看似简单，但 RAC 集群默认已建好 SYSAUX、SYSTEM、UNDOTBS1 等表空间，DESTROY=Y 只对对象生效，不会删表空间或改数据文件路径——结果是导入中途报 ORA-01652（无法扩展临时段）或 ORA-01119（创建数据文件失败）。
- 真正安全的做法是：先用
expdp按 schema 导出（如schemas=SCOTT,HR），跳过系统用户；再在 RAC 上提前建好对应表空间和用户 - 导入时加
remap_tablespace=USERS:+DATA/ORCL/DATAFILE/users01.dbf显式映射到 ASM 路径 - 如果必须全库导出，导入前先
drop tablespace USERS including contents and datafiles，再用create tablespace USERS datafile '+DATA' size 1g重建，否则DESTROY=Y无意义
最容易被忽略的是：RAC 中每个实例的 local_listener 和 remote_listener 必须指向 SCAN 地址，否则 srvctl start database 看似成功，实际只有节点1能连，节点2监听器根本没注册服务。
