autoupgrade.jar 不支持真正在线升级，数据库必须停机；必须手动更新为24.3.0版本，target_version仅设主版本，preupgrade_fixups.sql须人工执行，deploy阶段需手动处理时区和COMPATIBLE参数。
autoupgrade.jar 不支持真正意义上的“在线升级”——数据库必须停机，不存在不中断业务的全自动升级路径。所谓“在线”，是误传或混淆了 analyze 阶段可读库不锁库的特性；实际 deploy 阶段会执行 DRAIN（关闭实例）、DBUPGRADE（启动 upgrade 模式）、编译无效对象等操作，全程需数据库不可用。
以下实操要点基于 Oracle 官方当前（2026 年）强制要求与已验证失败案例整理：
autoupgrade.jar 版本必须手动更新到 24.3.0
oracle 19c 自带的 $oracle_home/rdbms/admin/autoupgrade.jar 是初始版（如 21.2 或 22.5），对 12c 源库识别不准，尤其漏检 wmsys.owm_vscript_pkg 等关键 invalid 对象，导致 deploy 阶段在 catqm.sql 报 ora-04043 直接中断。
- 从 MOS Note 2485457.1 下载
autoupgrade-24.3.0.jar（需有效 Support Identifier） - 替换命令：
cp autoupgrade-24.3.0.jar $ORACLE_HOME/rdbms/admin/autoupgrade.jar - 验证：
java -jar $ORACLE_HOME/rdbms/admin/autoupgrade.jar -version输出必须为24.3.0 - 不替换 →
analyze日志里不会提示 workspace manager 相关问题，但deploy必败
target_version=19 是主版本标识，不是补丁目标
target_version 参数只用于告诉 AutoUpgrade “你要升到哪个大版本”，它不控制补丁级别（RU）。实际部署时，AutoUpgrade 会读取 target_home 下 opatch lsinventory 所见的 RU 版本（如 19.24.0.0.0）作为真实目标。
- 错误写法：
upg1.target_version=19.24—— 被忽略，AutoUpgrade 只认整数 - 正确做法：先在
target_home打全最新 RU 补丁（如29585399），再运行analyze - 若 target_home 仍是
19.3.0.0，升级后DBA_REGISTRY显示的仍是19.3.0.0.0，而非预期的19.24.0.0.0
preupgrade_fixups.sql 必须人工执行，不能跳过
analyze 完成后生成的 preupgrade_fixups.sql（路径类似 /soft/upg_logs/lucifer/preupgrade/preupgrade_fixups.sql）不是建议脚本，而是强制修复清单。跳过等于埋雷。
- 典型内容包括：
ALTER SYSTEM SET compatible='11.2.0' SCOPE=SPFILE、DROP PACKAGE WMSYS.OWM_VSCRIPT_PKG、EXEC DBMS_DST.BEGIN_PREPARE(26) - 必须以
SYSDBA身份在源库执行，部分语句需重启生效 - 常见遗漏：未卸载 workspace manager 导致
deploy卡在catqm.sql；未调用DBMS_DST.BEGIN_PREPARE导致时区升级失败 - 执行后务必检查
dba_objects中是否仍有INVALID状态对象：SELECT owner, object_type, object_name FROM dba_objects WHERE status = 'INVALID'
deploy 阶段失败最常卡在时区和 COMPATIBLE
即使 analyze 和 fixups 全部通过，deploy 后仍可能因两个隐形依赖失败：时区版本未同步、COMPATIBLE 未手动设为目标值。
- 时区问题：日志中出现
"Database timezone version is 26. It is older than current release timezone version 43"→ 必须在升级后手动运行DBMS_DST系列过程（BEGIN_UPGRADE→UPGRADE_DATABASE→END_UPGRADE） -
COMPATIBLE参数：AutoUpgrade 不会自动修改该参数。升级完成后必须手动执行：ALTER SYSTEM SET compatible='19.0.0' SCOPE=SPFILE，然后重启库 - 二者均不处理 →
DBA_REGISTRY显示组件为 UPGRADED，但数据库实际处于“半升级”状态，后续打补丁或启用新特性会出错
preupgrade_fixups.sql 路径只出现在 analyze 的 console 输出末尾，而不是固定位置；而 deploy 失败时，真正的报错往往在子日志（如 catqm.log 或 postupgrade.log）里，不在主日志顶部。
