preupgrade.jar必须在11g环境中用11g的Java运行，是唯一可靠的预检方式；它能发现DBUA遗漏的关键兼容性问题，如SEC_CASE_SENSITIVE_LOGON废弃、时区文件版本不匹配、字符集Unicode版本差异及目录权限变更等，避免升级后密码失效、SYSTIMESTAMP异常、乱码或Data Pump失败。
直接运行 preupgrade.jar 是唯一可靠的方式，别信 DBUA 自带的预检——它漏掉的兼容性问题，往往导致升级后密码失效、对象编译失败或时区错乱。
preupgrade.jar 必须在 11g 环境中用 11g 的 Java 运行
很多人用 19c 的 JDK 执行 preupgrade.jar，结果报一堆“unknown parameter”或跳过关键检查。11g 数据库的元数据结构和参数定义与 19c 不兼容，工具必须匹配源库版本。
- 确认当前
$ORACLE_HOME指向 11g 安装路径（比如/u01/app/oracle/product/11.2.0/dbhome_1） - 执行命令：
java -jar $ORACLE_HOME/rdbms/admin/preupgrade.jar FILE TEXT DIR /tmp/preup - 输出的
preupgrade.log和preupgrade_fixups.sql必须人工逐条核对，尤其注意 “ERROR” 级别项，例如：SEC_CASE_SENSITIVE_LOGON已废弃但仍在启用，不处理会导致升级后所有密码登录失败
COMPATIBLE 参数值必须 ≥ 11.2.0
Oracle 官方明确要求源库 compatible 至少为 11.2.0 才能直升 19c。低于该值（如 11.1.0.7）必须先升级到 11.2.0.4 再升 19c，跳步会失败。
- 连接 11g 实例执行：
SHOW PARAMETER compatible - 若返回值低于
11.2.0，需在 11g 环境下执行：ALTER SYSTEM SET COMPATIBLE='11.2.0' SCOPE=SPFILE;，然后重启数据库 - 注意：不能设成
19.0.0—— 11g 实例根本无法识别，启动直接报错
字符集不是“看着一样就安全”
AL32UTF8 到 AL32UTF8 不等于零风险。11g 基于 Unicode 5.0，19c 支持 Unicode 13.0，中间新增的汉字、emoji、组合符号在升级后可能变成乱码或触发 ORA-12899（值太大）。
- 必须用 11g 自带的
csscan工具扫描全库：csscan full=y user=system - 再用 19c 提供的
csalter.plb验证转换可行性，而不是跳过检查直接升级 - 特别留意
NCHAR、NVARCHAR2和含TIMESTAMP WITH TIME ZONE的列，这些类型在字符集变更时行为更敏感
时区文件版本不匹配会静默破坏 SYSTIMESTAMP
预检脚本提示 “Timezone file version mismatch” 不是警告，是硬性阻断项。11g 默认用 v4 时区文件，19c 要求 v32+，否则 SYSTIMESTAMP 返回值偏移数小时，且无法回滚。
- 在 11g 数据库 OPEN 状态下，以 SYS 身份运行：
@$ORACLE_HOME/rdbms/admin/utltzuv2.sql - 该脚本会升级时区文件并重建
TIMEZONE$表，执行后必须重启数据库才生效 - 升级后验证：
SELECT VERSION FROM V$TIMEZONE_FILE;应返回 ≥ 32
最容易被忽略的是 preupgrade.jar 输出里那些带 “WARNING” 标签却没报错的项——比如 “Directory object privileges may be invalid”，19c 对 CREATE ANY DIRECTORY 权限校验更严，DBUA 不提示，但升级后 Data Pump 就卡死。这类问题不会让 DBUA 中断，但会让升级后第一轮导出导入彻底失败。
