不能在原11g实例上就地升级到19c，必须走异机迁移+逻辑dg滚动路径；autoupgrade仅适用于逻辑备库，主库全程保持11g运行至切换完成，因11g→19c跨大版本存在compatible参数硬限制及数据文件格式不兼容，强行就地升级会触发ora-00722或ora-01503错误。
直接说结论：不能在原11g实例上“就地升级”到19c，必须走异机迁移+逻辑dg滚动路径；autoupgrade只是其中一环，且只对备库生效，主库始终运行11g直到切换完成。
为什么不能直接在11g主库上跑autoupgrade？
autoupgrade设计初衷是单实例就地升级，但11g→19c跨大版本存在硬性限制：compatible参数无法从11.2.0.4一步跳到19.0.0，且19c内核不识别11g数据文件格式。强行执行会卡在ORA-00722: incompatible parameter "compatible"或ORA-01503: CREATE CONTROLFILE failed。官方明确要求：11g→19c必须通过逻辑DG实现主备跨版本共存。
autoupgrade必须在逻辑备库上执行，且SQL Apply必须停
常见错误是边同步边升级，结果触发ORA-00054: resource busy或升级进程静默挂起。原因在于autoupgrade要锁数据字典，而SQL Apply也在持续修改系统表。
- 先停同步：
ALTER DATABASE STOP LOGICAL STANDBY APPLY - 确认状态：
SELECT STATE FROM V$LOGSTDBY返回IDLE或APPLYING BATCH（不能是WAITING FOR LOGS） - 再执行：
autoupgrade -mode UPGRADE -oracleHome /u01/app/oracle/product/19c -config upgrade.conf
升级后不能直接RESUME，必须重建归档和补对象
很多人看到autoupgrade报告SUCCESS就以为完事，结果ALTER DATABASE START LOGICAL STANDBY APPLY失败——因为19c备库不认识11g主库新增的表、索引等对象，也不认旧的LOG_ARCHIVE_DEST_2配置。
- 用19c软件重建归档路径：
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=primary_db ...' SCOPE=BOTH - 补全主库升级期间新增的对象：
EXEC DBMS_LOGSTDBY.INSTANTIATE_TABLE('SCHEMA','TABLE_NAME') - 验证同步：
SELECT * FROM V$LOGSTDBY_PROGRESS中APPLIED_SCN应持续追平SELECT CURRENT_SCN FROM V$DATABASE（主库查）
最易被忽略的兼容性检查点
逻辑DG不是万能的，以下三项不提前处理，升级后必然同步中断：
- 主库必须启用补充日志：
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA - 所有复制表必须有主键或唯一约束，否则
V$LOGSTDBY_SKIP里会大量报UNIQUE CONSTRAINT VIOLATION -
LOB字段需确认是否为ENABLE STORAGE IN ROW，否则逻辑应用会跳过该列导致数据不一致
这些检查必须在建立逻辑备库前完成，而不是等autoupgrade报错再回退。
