如何在Oracle 19c RAC中实施跨版本的滚动升级操作？

不能直接在11g RAC上原地运行autoupgrade，因其不处理GI兼容性，而19c GI与11g数据库硬性互斥：11g实例无法注册集群、crsctl启动失败，OCR/ASM元数据格式变更导致ADG同步、归档、srvctl等不可预测中断。

autoupgrade 必须和逻辑 Data Guard 配合使用，不能单独在 RAC 上原地执行跨版本滚动升级；强行先升级 GI 到 19c 会导致 11g 实例无法注册集群、crsctl start resource 直接失败——这不是配置问题，是 Oracle 官方明确声明的硬性互斥限制。

为什么不能直接在11g RAC上原地运行autoupgrade？

因为 autoupgrade 工具本身不处理 grid infrastructure 版本兼容性，它只负责数据库软件和数据字典升级。而 11g rac 的运行强依赖于同版本 gi 中的 cssd、ohasd 等进程协议，19c gi 已移除或重构这些组件。

• OCR 和 ASM 磁盘组元数据格式在 19c 有变更，11g DB 无法识别
• 即使绕过启动检查挂载，后续 ADG 同步、归档日志写入、srvctl 命令都会不可预测中断
• autoupgrade -mode analyze 在 11g GI 下运行时，会拒绝识别“目标为 19c”的跨版本场景，报错类似 ORA-65535: upgrade not supported for this configuration

必须用逻辑DG搭建异机滚动通道

滚动升级的本质是“主备异版本并行运行”，不是原地替换。11g 主库保持在线，19c 备库通过逻辑复制同步变更，这是唯一被 Oracle 官方支持的跨大版本（11g→19c）零停机路径。

• 主库必须开启补充日志：ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;，否则逻辑 DG 启动即失败
• 提前筛查不支持对象：SELECT DISTINCT OWNER, TABLE_NAME, COLUMN_NAME, DATA_TYPE FROM DBA_LOGSTDBY_UNSUPPORTED;，含 ROWID、UROWID、XML、LOB 超长列（>4000 字节）的表需单独迁移
• 逻辑备库启用前，必须关闭 DG Broker（12.2.0.1 之前版本），否则 START LOGICAL STANDBY APPLY 会卡住
• 同步建立后，用 autoupgrade 升级的是逻辑备库本地数据库，此时主库仍为 11g，不受任何影响

升级后切换前最关键的三步验证

很多人看到 autoupgrade 报告 SUCCESS 就执行角色切换，结果应用连不上或查询报错——这是因为 compatible 参数不是自动设置的，且逻辑同步状态容易假性正常。

• 确认 compatible 已手动设为 '19.0.0'：ALTER SYSTEM SET compatible='19.0.0' SCOPE=SPFILE;，重启实例才生效
• 检查逻辑应用延迟：SELECT APPLIED_SCN, NEWEST_SCN FROM V$LOGSTDBY_PROGRESS;，差值超过 10 万 SCN 说明同步积压，切库必丢事务
• 验证关键对象有效性：SELECT OBJECT_NAME, STATUS FROM DBA_OBJECTS WHERE STATUS != 'VALID' AND ROWNUM ，无效对象未编译会导致应用首次调用失败

实际操作中最容易被忽略的是：逻辑 DG 切换后，原 11g 主库的监听器仍默认注册到旧 SCAN 地址，新应用连接会因 TNS 解析失败而超时——必须在切换前，用 srvctl modify scan -n 更新 SCAN 名称，并同步修改所有客户端的 tnsnames.ora。