备库升级必须停adg同步，主库业务不受影响；需先执行cancel中断日志应用，再shutdown immediate→替换oracle_home→运行catupgrd.sql→startup mount，完成后用using current logfile重新启用同步。
备库升级必须停ADG同步，但主库业务完全不受影响。这是 Oracle Data Guard 升级中最常被误解的一点：很多人以为“升级备库”就得停主库或切流量，其实只要操作得当，主库照常处理交易，用户零感知。
备库升级前必须关闭 ADG 同步
物理备库（Physical Standby）在 11g–19c 跨版本升级时，ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL 是强制前置步骤。不执行这一步就尝试启动到新版本，会报 ORA-16024: log_archive_dest_1 cannot be processed 或 ORA-19905: log_archive_format must contain %t, %s, %r 等归档路径/格式不兼容错误。
原因很直接：旧版备库的归档日志格式、控制文件结构、数据字典版本与 19c 不兼容，强行应用会导致介质恢复失败。所以必须先中断日志应用，把备库置于 MOUNT 状态再升级软件+启动实例。
- 执行顺序固定：
SHUTDOWN IMMEDIATE→ 替换 $ORACLE_HOME → 运行catupgrd.sql（仅对备库）→STARTUP MOUNT - 升级期间主库继续归档，所有 redo 日志仍正常生成并传输（
ARCH进程照常工作），只是备库暂不消费 - 升级完成后，用
RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT重新拉起同步
19c 备库必须用 OPEN READ ONLY WITH APPLY 启动
11g 备库默认只能 MOUNT 或 READ ONLY，而 19c 要求启用 Active Data Guard 才能边读边同步。如果只执行 ALTER DATABASE OPEN READ ONLY，后续启动实时应用会失败，报错 ORA-16000: database open for read-only access。
正确做法是先以 READ ONLY 打开验证数据一致性，再立刻切换为实时应用模式：
ALTER DATABASE OPEN READ ONLY; ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
这个组合确保了两点：一是跳过全量恢复（因已 mount 并升级完字典），二是避免手动 ALTER DATABASE OPEN 导致状态冲突。
- 若误用
STARTUP OPEN，实例会卡在MOUNTED状态且无法切换角色 - 升级后首次启动必须用 SQL*Plus 连接本地，不能依赖
srvctl start database（RAC 环境下尤其容易出错） -
USING CURRENT LOGFILE是关键参数，它让备库从当前在线日志开始追，而不是从归档起点重放，大幅缩短同步追赶时间
升级后切回主库前，switchover_status 必须为 TO PRIMARY
很多团队在备库升级完、同步追平后直接执行 ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY，结果报 ORA-16139: media recovery required。根本原因是没检查 v$database.switchover_status 的真实值。
这个字段不是“自动更新”的，它依赖后台进程持续比对主备 SCN 和日志序列号。升级后首次查询经常返回 SESSIONS ACTIVE 或 NOT ALLOWED，必须人工干预：
- 在备库执行
SELECT MAX(SEQUENCE#), THREAD# FROM V$LOG_HISTORY GROUP BY THREAD#，确认已应用到主库最新归档序列 - 主库执行
ALTER SYSTEM ARCHIVE LOG CURRENT强制切一次日志，再等 30 秒 - 再次查
v$database.switchover_status，直到显示TO PRIMARY才可执行切换 - 切前务必确认
db_unique_name和log_archive_config在主备两端完全一致，否则SWITCHOVER会静默失败
跨版本升级最易忽略的三个配置项
升级后即使同步跑起来，也可能在后续 Switchover 或故障转移时突然失败。问题往往出在三个看似无关紧要的初始化参数上：
-
compatible=19.0.0：必须在升级完成后立即修改，并重启备库生效。11g 的compatible=11.2.0会阻止 19c 新特性调用，导致DBMS_ROLLING或FLASHBACK DATABASE失效 -
log_archive_dest_2中的VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)：11g 写法在 19c 下会被忽略，必须显式补全VALID_FOR=(ALL_LOGFILES,ALL_ROLES)，否则 Switchover 后归档路径失效 -
db_file_name_convert和log_file_name_convert：如果主备文件路径不一致，升级后必须用ALTER SYSTEM SET ... SCOPE=SPFILE重设，否则新主库启动时报ORA-01180: can not create datafile 1
这些参数不会在升级过程中报错，但会在第一次角色切换时集中爆发——所以升级完成≠万事大吉，switchover_status 和参数校验必须手工逐条确认。
