升级前必须在11g的oracle_home下执行preupgrade.jar，使用11g的jdk运行，否则会因环境不匹配导致noclassdeffounderror或连接失败；dbua等工具各阶段对oracle_home要求不同，需严格分阶段切换，避免全局覆盖引发隐性错误。
升级前必须切换到源库的ORACLE_HOME执行预检
预升级检查脚本preupgrade.jar依赖源库（11g）的JDK和环境，不是19c的。用错ORACLE_HOME会导致java.lang.NoClassDefFoundError或连接失败。
- 先确认当前是11g环境：
echo $ORACLE_HOME应输出类似/u01/app/oracle/product/11.2.0/db_1 - 运行命令必须显式调用11g的
java：/u01/app/oracle/product/11.2.0/db_1/jdk/bin/java -jar /u01/app/oracle/product/19.3.0/dbhome_1/rdbms/admin/preupgrade.jar TERMINAL TEXT - 切勿在19c的
ORACLE_HOME下直接执行sqlplus连11g库再跑脚本——会因NLS、字符集或网络配置差异引发隐性错误
ORACLE_HOME切换必须分阶段，不能全局覆盖
升级过程中存在多个关键阶段，每个阶段对ORACLE_HOME的要求不同：DBUA或dbupgrade启动时需指向19c，但连接源库仍要靠11g的客户端能力。硬编码或export全局变量极易导致进程找不到对应lib或network/admin配置。
- DBUA静默模式中，
-oracleHome参数必须指定11g路径，-targetOracleHome才指定19c路径；顺序颠倒会报ORA-01017（实为路径解析失败） - 手动执行
dbupgrade前，临时切换ORACLE_HOME到19c，但PATH里仍需保留11g的bin（例如用于expdp或sqlplus连接验证） - RAC环境尤其危险：节点间
ORACLE_HOME不一致会导致CRS资源注册失败，crsctl stat res -t显示OFFLINE
Windows平台要额外清理注册表残留
Windows上Oracle服务、监听器、环境变量常通过注册表固化，仅修改当前shell的ORACLE_HOME无效。旧版本服务若仍引用11g路径，会在升级过程中抢占有用端口或写入错误日志路径。
- 检查注册表项：
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_<i>your_oracle_home_name</i>，确认ORACLE_HOME值与实际11g安装路径一致 - 升级后启动19c监听器前，运行
lsnrctl stop并手动删除%ORACLE_HOME%\network\log\listener.log——否则可能沿用11g格式日志，导致19c监听无法加载 - PL/SQL Developer等客户端若报
ORA-12154，大概率是其读取了注册表里的旧TNS_ADMIN，而非当前shell设置的路径
升级后立即验证ORACLE_HOME是否被DBA误设回11g
很多DBA在升级完成后习惯性执行source ~/.bash_profile，而该文件里往往还留着11g的ORACLE_HOME导出语句。此时sqlplus / as sysdba看似能连，实则走的是11g客户端，后续执行ALTER DATABASE OPEN UPGRADE会失败。
- 升级成功后第一件事：在新实例下运行
SELECT * FROM v$version;，确认输出含19.0.0.0.0 - 然后立刻检查
$ORACLE_HOME是否已切至19c，并且$PATH头部是$ORACLE_HOME/bin - 特别注意RMAN：如果
rman target /调用的是11g的二进制，备份脚本中BACKUP DATABASE PLUS ARCHIVELOG可能跳过19c新增的数据文件类型（如SYSAUX$表空间中的新对象）
环境变量不是配一次就完事的事，它在升级流程中是动态上下文，每个命令背后都绑定了特定版本的二进制和配置边界。最容易被忽略的是RAC节点间的一致性校验，以及Windows注册表与shell变量的双重控制关系。
