物理standby无法用于12c→19c滚动升级，因19c mrp无法解析12c redo日志格式，启动即报ora-16470；必须通过逻辑standby或dbms_rolling实现跨版本升级。
Oracle Data Guard 本身不直接支持滚动升级，必须配合逻辑 Standby、DBMS_ROLLING 或手动切换流程才能实现跨大版本的滚动升级。 物理 Standby 无法跨主版本同步（比如 12c → 19c），直接启用 MRP 就会报 ORA-16470；而逻辑 Standby 或 DBMS_ROLLING 才是真正能支撑“主库不动、备库先升、再切角色”这一滚动逻辑的机制。
为什么物理 DG 不能直接用于 12c→19c 滚动升级
19c 的 MRP 进程无法解析 12c 生成的 redo 日志格式，这是硬性限制：
-
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY会直接报ORA-16470，不是配置问题，是内核级不兼容 - 即使强行创建 12c 主库到 19c 物理备库，
V$ARCHIVED_LOG.APPLIED始终为NO，MRP 启动即失败 - DBUA 或
dbupgrade只允许同主版本内升级（如 12.2.0.1 → 12.2.0.2），跨主版本（12c → 19c）必须绕过物理复制路径
逻辑 Standby 是跨版本滚动升级的实际载体
逻辑 Standby 基于 SQL Apply，不依赖块级一致性，因此可桥接主备两端不同 Oracle 主版本：
- 先将物理 Standby 转为逻辑 Standby：
ALTER DATABASE RECOVER TO LOGICAL STANDBY（需提前停 MRP、清空 standby redo log） - 转换后，主库（12c）仍持续归档，逻辑备库（19c）用
LOGSTDBY进程解析并执行 DML/DDL —— 此时升级操作可在备库上静默进行 - 注意：逻辑 Standby 不支持部分对象（如
XMLType、物化视图日志、某些 UDT），升级前必须运行DBMS_LOGSTDBY.SKIP或DBMS_LOGSTDBY.UNSKIP显式声明兼容性 - 验证逻辑同步是否稳定：
SELECT * FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'COORDINATOR'状态应为APPLYING，且EVENTS列无报错
DBMS_ROLLING 包是官方推荐的自动化滚动升级工具
DBMS_ROLLING 是 Oracle 12c+ 提供的 PL/SQL 包，封装了切换、校验、回退等步骤，但要求严格满足前提条件：
- 主备库都必须开启
FLASHBACK：SELECT FLASHBACK_ON FROM V$DATABASE返回YES -
COMPATIBLE参数至少设为12.1.0（11g 升 19c 需先调高至 12.1） - Data Guard Broker 必须禁用：
ALTER SYSTEM SET DG_BROKER_START=FALSE，否则DBMS_ROLLING.START_ROLLING会报ORA-16665 - 执行前必须建立 Guaranteed Restore Point（GRP）：
CREATE RESTORE POINT pre_upgrade GUARANTEE FLASHBACK DATABASE，后续任何失败都靠它闪回
Switchover 卡住最常见的三个漏检点
哪怕只漏一项，ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY 就会 hang 或报 ORA-16139：
-
SELECT SWITCHOVER_STATUS FROM V$DATABASE必须返回TO PRIMARY（不是SESSIONS ACTIVE，也不是SWITCHOVER PENDING） - 所有线程的归档必须已应用完毕：
SELECT THREAD#, MAX(SEQUENCE#), APPLIED FROM V$ARCHIVED_LOG GROUP BY THREAD#, APPLIED，每个APPLIED='YES'的最大SEQUENCE#必须等于主库当前V$LOG.SEQUENCE# - 所有捕获进程必须彻底停止：
SELECT CAPTURE_NAME, STATE FROM DBA_CAPTURE应为空，GoldenGate、CDC、Streams 若残留 RUNNING 状态，switchover 会无限等待队列清空
真正难的不是命令怎么敲，而是每一步背后的状态校验是否扎实——比如 V$LOGSTDBY_PROGRESS 里的 APPLIED_SCN 和主库 V$DATABASE.CURRENT_SCN 差值超过 1000，就别急着切；又比如 GRP 创建后没做 FLASHBACK DATABASE 测试，真出问题时回退可能失败。这些细节不写进 checklist，很容易在凌晨三点卡住。
