不能直接在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。
