DBUA升级失败应先查$ORACLE_BASE/cfgtoollogs/dbua下日志，重点排查权限、/tmp空间、监听器、图形环境、时区文件、preupgrade.jar深度检查、字符集兼容性及升级后DBA_REGISTRY和utlrp.sql验证。
DBUA 升级失败时先看 dbua 日志位置和关键错误类型
dbua 升级中途卡住或报错，别急着重跑，dbua 默认把详细日志写在 $oracle_base/cfgtoollogs/dbua 下，按数据库名分目录。最常绊倒人的不是功能缺失，而是权限和路径问题：比如 oracle 用户对 $oracle_home 没有写权限、/tmp 空间不足（dbua 会解压大量临时文件）、或者监听器没起来导致连接校验失败。
-
ORA-01034: ORACLE not available—— 不是数据库挂了，大概率是 DBUA 找不到监听器，检查lsnrctl status和TNS_ADMIN环境变量是否指向正确的tnsnames.ora - 升级界面白屏/无响应 —— 多半是图形环境没配好，改用静默模式更稳：
dbua -silent -sid <code>ORCL-oracleHome/u01/app/oracle/product/19c/dbhome_1-sourceDBHome/u01/app/oracle/product/11.2.0/dbhome_1 - 预检阶段提示
“Timezone file version mismatch”—— Oracle 11g 默认用 v4 版本时区文件，19c 要 v32+，得提前运行utltzuv2.sql升级时区，否则升级后SYSTIMESTAMP行为异常
预检脚本 preupgrade.jar 必须在旧库上运行，不是可选项
很多人以为 DBUA 自带的预检够用，其实它只做基础检查；preupgrade.jar 是 Oracle 官方强推的深度扫描工具，必须在 11g 数据库启动状态下、用 11g 的 java 运行（不能用 19c 的 JDK），否则会漏掉关键兼容性问题，比如 SEC_CASE_SENSITIVE_LOGON 参数在 12c+ 已废弃但 11g 还开着，不处理会导致升级后密码登录失败。
- 执行命令：
java -jar $ORACLE_HOME/rdbms/admin/preupgrade.jar FILE TEXT DIR /tmp/preup，输出的preupgrade.log和preupgrade_fixups.sql必须逐条确认 - 重点盯
“WARNING”和“ERROR”级别项，比如“Database contains INVALID objects”—— DBUA 不会自动编译，得手动运行@?/rdbms/admin/utlrp.sql清理 - 如果用了 Data Pump 导出过对象，检查
“Directory object privileges”是否仍有效，19c 对CREATE ANY DIRECTORY权限校验更严
字符集不兼容时，AL32UTF8 到 AL32UTF8 不等于安全
看起来都是 AL32UTF8，但 11g 和 19c 对 Unicode 标准支持版本不同（11g 是 Unicode 5.0，19c 是 13.0），某些增补汉字或 emoji 在升级后可能变成乱码或报 ORA-12899。真正保险的做法不是跳过检查，而是用 csscan（11g） + csalter.plb（19c）做双向扫描和转换验证。
- 运行
csscan full=y前确保数据库已启用COMPATIBLE=11.2.0，否则扫描结果不准 -
csalter.plb只能在升级后、OPEN 状态下运行，且要求数据库为空闲状态（无 DML），否则报ORA-01092 - 如果原库含
ZHS16GBK字符集，别硬转，先评估业务能否接受AL32UTF8，否则得走 expdp/impdp 全量迁移，DBUA 不支持跨字符集就地升级
升级后立刻验证 DBA_REGISTRY 和 utlrp.sql 编译状态
DBUA 显示 “Success” 不代表实例就绪。常见疏漏是没查 DBA_REGISTRY 里组件状态是否全为 VALID，尤其 ORDIM（Oracle Multimedia）和 XDB（XML DB）在 11g 到 19c 路径变更大，容易卡在 LOADING 或 INVALID。另外，utlrp.sql 编译耗时长，但必须等它跑完才能确认 PL/SQL 功能正常。
- 查组件状态：
SELECT comp_name, status, version FROM dba_registry ORDER BY modified DESC;—— 任何非VALID都要查对应$ORACLE_HOME/rdbms/admin/xxx.sql手动重装 - 编译前先设
ALTER SYSTEM SET job_queue_processes=10;，否则utlrp.sql默认只用 1 个 job，百万级对象可能卡几小时 - 升级后首次连接用
sqlplus / as sysdba，别用 TNS —— 因为listener.ora还没自动更新 19c 的ORACLE_HOME路径，直连绕过监听更可靠
真正麻烦的不是步骤多，是每个环节都依赖上一个环节的干净收尾。比如预检没清掉 INVALID 对象，DBUA 可能跳过但后续 utlrp.sql 会反复失败；又比如字符集扫描漏了隐藏的 CLOB 字段编码，上线后某张报表突然导出乱码——这种问题不会报错，只会悄悄咬人。
