迁移前必须确认RAC特有依赖项：共享存储、OCR/Voting Disk、GI状态、INSTANCE_NAME与DB_NAME分离；需启用ARCHIVELOG；GI/RDBMS版本及权限一致；提前创建ASM磁盘组；RMAN DUPLICATE需设DB_CREATE_FILE_DEST等参数；Data Pump须禁用并行；手工配置service与listener。
迁移前必须确认的 RAC 特定依赖项
单实例数据库迁移到 rac 不是“备份还原”就能完事的，rac 的共享存储、ocr/voting disk、gi 状态、实例名（instance_name）和数据库名（db_name）分离这些底层约束会直接让 rman 或 data pump 失效。比如用 duplicate target database to ... 时若没提前在目标节点注册 +asm 实例或没配置好 spfile 中的 cluster_database=true，rman 会在启动辅助实例阶段报 ora-01078: failure in processing system parameters。
- 检查源库是否启用了
ARCHIVELOG模式——RAC 要求必须归档，否则 RMAN 增量恢复无法跨实例同步 - 确认目标 RAC 所有节点已安装相同版本 GI 和 RDBMS，且
ORACLE_HOME权限一致；混用 patch set 可能导致ORA-15032或 ASM diskgroup mount 失败 - 提前在 RAC 上创建好裸设备或 ASM diskgroup（如
+DATA），并确保所有节点都能通过asmcmd lsdg看到，否则 Data Pump 导入时DIRECTORY对应路径会不可写
RMAN DUPLICATE 是首选，但得绕开几个默认陷阱
RMAN DUPLICATE 比 Data Pump 更适合结构+数据整体迁移，因为它能自动重建控制文件、重做日志组，并适配 RAC 的多实例 redo thread。但它的默认行为是按单实例逻辑走：比如不显式指定 NOFILENAMECHECK，它会尝试在原路径创建数据文件，而 RAC 要求所有数据文件必须在共享存储上，路径需统一为 ASM 别名（如 +DATA/dbname/datafile/system.256.12345）。
- 执行前在目标 RAC 上运行
CREATE SPFILE FROM PFILE，确保SPFILE已启用且含thread=1（后续可加 thread 2）、undo_tablespace=UNDOTBS1等 RAC 必需参数 - DUPLICATE 命令中必须包含
SET DB_CREATE_FILE_DEST='+DATA'和SET DB_RECOVERY_FILE_DEST='+FRA'，否则 RMAN 仍会尝试写本地文件系统 - 若源库有加密表空间（TDE），需提前把源库的
ewallet.p12拷贝到每个 RAC 节点的$ORACLE_HOME/admin/$ORACLE_SID/wallet并执行ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN
Data Pump 只适合对象级迁移，且必须禁用并行导出
用 expdp/impdp 迁移，本质是逻辑复制，跳过了物理结构适配，所以不能替代 RMAN。但它对大表分区、特定 schema 或需要过滤数据的场景更灵活。问题在于：RAC 下 expdp 默认启用并行（PARALLEL=4），而并行进程可能被调度到不同节点，导致 DIRECTORY 路径在某节点不可见，报错 ORA-39002: invalid operation 或 ORA-39070: Unable to open the log file。
- 导出时强制设
PARALLEL=1，并在一个固定节点（如 node1）执行，DIRECTORY必须指向共享存储上的路径（如CREATE DIRECTORY dp_dir AS '+DATA/dump';） - 导入前在 RAC 所有实例上执行
ALTER SYSTEM SET cluster_database_instances=2 SCOPE=SPFILE（数字按实际实例数填），否则impdp可能只在一个实例上建对象，引发序列/同义词跨实例不可见 - 避免使用
TRANSFORM=SEGMENT_ATTRIBUTES:N，RAC 对本地管理表空间的 segment 属性（如INITIAL、NEXT）敏感，硬编码会导致 extent 分配失败
验证阶段最容易漏掉的是 service 和 listener 配置
迁移完成后，应用连不上，90% 不是因为数据不对，而是 service 没注册进 SCAN listener，或者 tnsnames.ora 里写的 SERVICE_NAME 和 RAC 实际运行的不一致。RMAN 或 Data Pump 都不会动这些网络层配置，必须手工补全。
- 检查
srvctl config service -d <db_name></db_name>输出是否包含你期望的服务名（如myapp_svc），没有就用srvctl add service加 - 确认每个节点的
listener.ora中GLOBAL_DBNAME设为<db_name>.<domain></domain></db_name>（不是 SID），否则 SCAN VIP 无法路由连接 - 用
sqlplus /@<scan_name>:<port>/<service_name></service_name></port></scan_name>测试连接，别只连localhost:1521/<sid></sid>——后者绕过了 RAC 的负载均衡和故障转移机制
真正卡住人的从来不是命令敲错，而是 OCR 中 service 状态显示 ONLINE，但 lsnrctl status 在某个节点看不到该 service 的 handler。这种不一致只能靠 crsctl stat res -t | grep service 和逐节点查 listener 日志交叉验证。
