Oracle 12c RAC迁移到19c怎么做？使用Data Guard切换

Oracle 12c RAC 到 19c RAC 的 Data Guard 切换是否可行？

先说结论：这事儿能办，但路径得选对。它并非一次“原地升级式”的直接切换，而是必须遵循跨版本物理备库搭建、滚动升级、最终切换的标准流程。原因很简单，12c和19c属于不同的主版本，当你尝试执行 alter database commit to switchover 时，版本差异过大（大于一个主版本）会直接触发 ORA-16470 错误。所以，通过物理Data Guard进行在线迁移，是官方唯一支持的稳妥方法。

为什么不能直接在 12c 主库上建 19c 物理备库？

这里有个核心限制：Oracle不允许跨主版本直接搭建物理备库。问题的关键在于Redo日志格式——19c实例的MRP（托管恢复进程）压根儿识别不了12c主库发来的低版本日志。那么，正确的打开方式是什么呢？答案是，得先让目标端“伪装”成兼容版本。

• 首先，在计划中的19c RAC环境上，安装与源端完全一致的12.2.0.1数据库软件，并创建一个空实例作为临时备库。
• 接着，让这个12.2的临时备库正常接收并应用来自12c主库的Redo，保持数据同步。
• 待同步状态稳定后，在备库侧执行DBUA或手动升级操作至19c（此过程需暂停MRP，升级完成并重启实例后，再重新启动MRP）。
• 最后，升级完成后务必验证数据字典的一致性（确保catuppst.sql执行无误），并以只读模式打开备库确认数据可访问。至此，才算是具备了执行Switchover的资格。

Data Guard 切换前最关键的三个验证点

这三个验证点，可以说是切换前的“必修课”。跳过任何一步，都极有可能在Switchover过程中卡在 ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY 这一步，或者冷不丁地冒出个 ORA-16139（归档日志缺失）错误。

• 切换状态检查：查询 SELECT SWITCHOVER_STATUS FROM V$DATABASE，返回值必须是 TO PRIMARY。如果看到 SESSIONS ACTIVE 或 SWITCHOVER PENDING，那就说明条件还不成熟。
• 日志同步确认：确保所有归档日志均已传输并应用完毕。执行 SELECT MAX(SEQUENCE#), APPLIED FROM V$ARCHIVED_LOG GROUP BY APPLIED，核对 APPLIED='YES' 的最大序列号，是否与主库当前 LOG_ARCHIVE_DEST_2 目标中的 ARCHIVED_THREAD# 一致。
• 高级复制进程清理：检查 DBA_LOG_GROUPS 和 DBA_CAPTURE。如果存在已启用的GoldenGate或Streams捕获进程，必须在切换前将其停用。否则，Switchover操作会因为这些未停止的进程而一直挂起。

切换后 19c 新主库上最容易被忽略的配置项

Switchover成功完成，往往让人松一口气，但真正的考验可能才刚刚开始。在19c实例正式接管后，有几个配置细节如果忘了调整，后续的备份、监听甚至集群资源都可能出问题。

• 监听配置更新：local_listener 参数很可能还指向旧的12c SCAN名称或IP地址。需要立即使用类似 ALTER SYSTEM SET LOCAL_LISTENER='(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=rac19-scan)(PORT=1521)))' 的命令进行更新，并在每个节点执行 ALTER SYSTEM REGISTER 使配置生效。
• 归档路径修正：log_archive_dest_1 中的 LOCATION 路径如果仍然写着12c时代的ASM磁盘组名（例如 +FRA12），而19c RAC实际使用的是新磁盘组（如 +FRA19），将直接导致归档失败。必须将其修改为有效的当前路径。
• 集群资源绑定：OCR（Oracle集群注册表）中的数据库资源名称默认不会自动更新版本号。建议在切换后，运行 srvctl modify database -d xxx -o $ORACLE_HOME 命令，显式地将数据库资源绑定到新的19c Oracle Home目录。

话说回来，19c的 ADG（Active Data Guard）自动间隙修复机制确实比12c更主动。但是，一旦遇到加密钱&包（Wallet）未打开、TDE密钥未同步，或者备用重做日志文件权限不正确等情况，这个“自动”功能就会失效。这些细节问题，在切换前的测试环境中常常难以完全暴露，却非常喜欢在生产割接的关键时刻突然现身，需要格外警惕。