备库升级前必须确认3个前提条件：DB_UNIQUE_NAME与LOG_ARCHIVE_CONFIG中DB名一致、COMPATIBLE参数不高于目标版本、备库处于MANAGED RECOVERY且APPLYING_LOG为YES。
备库升级前必须确认的 3 个前提条件
直接在备库上升级再切换，不是所有环境都适用。如果跳过验证，很可能切完主库就起不来。
-
DB_UNIQUE_NAME和LOG_ARCHIVE_CONFIG中的 DB 名必须一致，否则切换后日志传输中断，ORA-16778或ORA-16826高概率出现 - 主备库的
COMPATIBLE参数值不能高于目标版本（例如升到 19c，当前COMPATIBLE不能是'21.0.0'） - 备库必须处于
MANAGED RECOVERY状态且APPLYING_LOG为YES，用SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;确认，否则升级后无法正常应用日志
升级备库时如何避免“升级成功但无法接管”
很多人在备库跑完 runInstaller 就以为完事了，其实最关键的步骤在后面——数据库字典和组件升级必须手动触发。
- 升级 Oracle Home 后，用新 home 的
sqlplus / as sysdba连上备库，执行STARTUP MOUNT（不能OPEN） - 运行
@?/rdbms/admin/catuppst.sql，这是 12c+ 版本必需的 post-upgrade 脚本，漏掉会导致DBA_REGISTRY中组件状态异常 - 执行
ALTER DATABASE OPEN RESETLOGS前，先查V$DATABASE.OPEN_MODE，必须是MOUNTED；如果误开成READ ONLY，RESETLOGS会报ORA-01589
切换角色时最常卡住的两个地方
执行 SWITCHOVER TO 不是命令一敲就完，实际卡住往往是因为归档未同步或 Broker 配置残留。
- 主库执行
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;后，必须等V$DATABASE.SWITCHOVER_STATUS = 'TO PRIMARY'才能在原备库执行下一步，不能凭时间猜测 - 如果用了 Data Guard Broker，升级前必须停掉
DGMGRL并清空broker_config_file（默认在$ORACLE_HOME/dbs/dr1<db_name>.dat</db_name>），否则新版本 DG Broker 读旧配置会报ORA-16698
切换后主库启动失败的快速定位方法
新主库起不来，别急着重装，90% 的问题出在归档路径或密码文件上。
- 检查
ARCHIVE_LAG_TARGET和LOG_ARCHIVE_DEST_1是否还指向旧主库路径，升级后这些参数不会自动更新，需手工改回本地归档 - 确认
orapw<sid></sid>文件已从旧主库拷贝到新主库对应目录，且权限是640；否则ORA-01017会掩盖真实问题 - 查看
alert.log中第一条报错后的连续 5 行，重点关注Archived Log、Redo Thread、Control file相关关键词，比盲目重启更省时间
整个过程里最容易被忽略的是密码文件同步时机——它必须在切换完成、新主库首次 STARTUP 之前完成，而不是升级 Oracle Home 时。
