简介：面向具备一定运维能力的数据库管理员的 Oracle 升级实操手册，聚焦用 DBUA 工具把 11g 单机库安全迁移到 19C 这一典型维护场景。内容覆盖升级前的兼容性与主机版本核查、升级路线判定（11.2.0.4 及以上可直达 19.x，低版本需经中间版本过渡）、生产库用 RMAN 备份恢复到目标库并保留回退环境、参数文件恢复与目录重建，以及 DBUA 图形与静默两种执行方式、升级后配置调整和日志警告排查，并附多类故障处理方案。包内为 1 个 PDF 文件，约 3.18MB，按操作顺序编排，便于对照执行与逐项打钩。已有 1361 人学习下载。读者可据此理清升级前置条件与风险点，掌握备份恢复与回退思路，减少停机与返工。

1. ORA-12541 卡在 DBUA 预检查：这类翻车比想象中常见

ORA-12541: TNS:no listener报在 DBUA 预检查界面，进度条停在 20% 不动——做 11g 升 19C 的人，多数在这个位置愣过几分钟。DBUA 的特点是把风险全堆在前面：预检查、时区、组件、监听，任一项不过关就不让往下走；更麻烦的是它只说「失败」，很少说「为什么」。这份 Oracle 19C 升级手册把 DBUA 路径上的报错拆开写清楚了：哪些是硬门槛（版本路线、操作系统）必须换机器，哪些是配置问题改两行参数就能过，哪些是 RMAN 恢复阶段留下的归档缺口。适合正在做 Oracle 11g 到 19C 迁移的 DBA，也适合第一次跑 DBUA 就卡住、想弄清根因的运维。

2. 预检查就过不去：版本路线与操作系统这两道硬门槛

DBUA 的预检查失败里，有一半根本不是「配置写错了」，而是源库或主机压根不在支持矩阵里。这类问题改参数、调监听、重启实例全都没用，只会把时间浪费掉。先花十分钟把这两道门槛确认掉，后面的排查才有意义。

2.1 11.2.0.3 直升级 19C 必然失败，先把版本推到 11.2.0.4

DBUA 给出的提示通常很含糊，比如「the selected database version is not supported for upgrade」，或者干脆在预检查列表里标一个红色的不支持项。很多人第一反应是去查补丁、查兼容性参数，其实根因只有一个：19C 的直升级路线只认 11.2.0.4 及以上。

先确认源库的精确版本，别用「我记得是 11g」这种印象派判断：

-- 源库上执行，banner_full 能精确到补丁集，比 v$instance.version 更细 select banner_full from v$version; -- 看历史上打过哪些补丁，确认是否已经是 11.2.0.4 加某个 PSU select * from registry$history order by action_time;

如果输出是Oracle Database 11g Enterprise Edition Release 11.2.0.3.0，那就别折腾 DBUA 了，路走不通。官方的升级路线只有下面这几种：

中转这一步别想着偷懒。11.2.0.3 到 11.2.0.4 是个完整的补丁集升级，要在源库上正常做完，验证组件状态、编译无效对象，然后再谈 19C。我见过有人想跳过这步、直接把 11.2.0.3 的数据文件挂到 19C 上，结果是 DBUA 直接拒绝，连预检查都跑不完。

还有一种隐蔽情况：版本是 11.2.0.4，但dba_registry里有组件处于INVALID或者LOADED状态。DBUA 同样会在预检查里报错，提示组件需要先处理。这个放到 4.3 节展开。

2.2 主机还是 Linux 6 就别硬上了：19C 最低要求 RHEL/OL 7

这是最容易被忽略、也最没有回旋余地的一条。19C 对操作系统的认证下限是 Linux 7，源库如果跑在 Linux 6 上，DBUA 在预检查阶段可能只是给个 WARNING，让你误以为能继续，实际到组件升级那一步会报一堆莫名其妙的错误，比如ORA-00439: feature not enabled，或者 Java 虚拟机起不来。

先确认主机版本，别相信别人交接时说的「我们是 7」：

# 确认发行版本与内核，两个都要看 cat /etc/oracle-release uname -r # 确认 glibc 版本，19C 对 glibc 有最低要求 ldd --version | head -1

常见的坑是：/etc/redhat-release显示 7.x，但内核是从 6 上带过来的自定义内核，或者 glibc 被人手工降级过。这种「看着像 7 其实是 6」的环境，装 19C 软件时会直接报缺失依赖包，报错里全是.so文件名。

处理方式只有一条：另起一台 Linux 7（或 8）的主机，装好 19C 软件，再用 RMAN 把生产库恢复到新主机上升级。这也是为什么升级方案里必须有「恢复」这一步，而不是原地升级——源库继续对外服务，目标库随便折腾，失败了大不了重来一遍。

注意：主机换代意味着/etc/hosts、/etc/security/limits.conf、大页内存、共享内存参数、防火墙端口全部要重新配一遍，这些不属于 DBUA 的检查范围，但会在升级到一半时以「实例起不来」的形式爆发。

2.3 preupgrade.jar 的三个产出文件，只看日志等于白跑

预检查最靠谱的入口不是 DBUA 的图形界面，而是官方那个 preupgrade 脚本。它跑在源库上，输出比 DBUA 的预检查页详细得多，而且给出的修复脚本是可以直接执行的。

# 在 11.2.0.4 源库上执行，用源库自带 JDK $ORACLE_HOME/jdk/bin/java -jar /home/oracle/preupgrade.jar \ FILE TEXT DIR /home/oracle/preupgrade # 目录里会出现三个文件，缺一不可 ls -l /home/oracle/preupgrade/

三个参数的含义：FILE表示把结果写进文件而不是只打印到终端（生产环境建议一定加，输出很长，滚屏会丢信息）；TEXT指定输出纯文本格式，比 XML 好读；DIR指定输出目录，这个目录必须提前建好且 oracle 用户可写，否则脚本会静默失败，只在终端留一行找不到目录的提示。

产出物里preupgrade.log是主报告，按ERROR、WARNING、INFO分级；preupgrade_fixups.sql要在源库上执行；postupgrade_fixups.sql要在升级完成后执行。后两个文件被忽略是高频翻车点——有人只看了日志，觉得「就几个 WARNING，无所谓」，结果升级完发现时区版本不对、密码全部失效。

日志里最值得盯的三类内容：一是时区文件版本（下一章和 4.2 节都会提到），二是需要重新编译的无效对象清单，三是dba_registry里状态异常的组件。这三类如果留到 DBUA 阶段处理，就得回退重来。

3. 用 RMAN 搬到升级环境：从参数文件到归档缺口

目标库上的恢复质量，直接决定 DBUA 能不能跑完。这一章记录了从参数文件恢复一路走到「打开只读再追归档」的完整过程，中间会撞上RMAN-06054，这个报错背后的逻辑值得单独说清。

3.1 先恢复 spfile 再改 pfile：路径、db_name、db_unique_name 三处必改

直接从备份里恢复 spfile 是最省事的起点，但恢复出来的 spfile 里存的都是源库的路径，直接用它启动会报ORA-00205: error in identifying control file或者ORA-01078: failure in processing system parameters，因为你根本没有那个目录。

# 先起到 nomount，只为了把 spfile 捞出来 rman target / RMAN> startup nomount; RMAN> restore spfile from '/backup/srcdb_spfile_20240301.ora'; RMAN> exit # 转成 pfile，目的是能手工编辑 sqlplus / as sysdba SQL> create pfile='/home/oracle/pfile_upg.ora' from spfile; SQL> exit

接下来把 pfile 里三类参数改掉：控制文件路径（control_files）、审计与诊断目录（audit_file_dest、diagnostic_dest）、以及db_unique_name。db_name一般保持和源库一致，db_unique_name加个后缀区分，这样两套库在同一个网络里不会互相干扰。

# 建好 pfile 里引用的新目录，否则启动时报 ORA-27040 / ORA-27041 mkdir -p /u02/app/oracle/admin/upgdb/adump mkdir -p /u02/oradata/upgdb/controlfile # 用编辑好的 pfile 起来，再反向生成 spfile，落进 19C 的 home sqlplus / as sysdba SQL> startup nomount pfile='/home/oracle/pfile_upg.ora'; SQL> create spfile from pfile='/home/oracle/pfile_upg.ora'; SQL> exit

改参数时有两个容易漏的点。一是memory_target这类参数照抄源库会很危险：源库是 128G 的机器，目标库可能只有 64G，实例起不来只报一句ORA-00845: MEMORY_TARGET not supported on this system，看不出是内存不够。二是compatible参数，源库上写着11.2.0.4.0，恢复到目标库后不要急着改，等 DBUA 升级完成再动，提前改成 19 的参数会让升级脚本行为异常。

3.2 控制文件、catalog、SET NEWNAME：顺序错了就白跑

控制文件恢复完必须 mount 才能做后续操作，这是硬顺序。catalog start with的作用是把备份目录里的文件登记进控制文件，不执行这一步，restore database会告诉你找不到可用的备份。

rman target / # 恢复控制文件，注意文件名要写备份片里的实际名字 RMAN> restore controlfile from '/backup/srcdb_control_20240301.ctl'; # 必须 mount，nomount 状态下 catalog 不生效 RMAN> sql 'alter database mount'; # 扫描整个备份目录，把备份集登记进控制文件 RMAN> catalog start with '/backup/'; # 确认登记结果与数据文件清单 RMAN> list backup summary; RMAN> report schema;

catalog start with重复执行是安全的，已经登记过的备份集会被跳过，终端上提示 already cataloged，不用管。真正需要留意的是report schema的输出：如果数据文件路径还显示成源库的 ASM 或者旧目录，说明控制文件里的记录没被SET NEWNAME覆盖，后面恢复出来的文件会散落在各处。

恢复数据文件时把SET NEWNAME和SET UNTIL TIME一起用：

run { # 通道数决定并行度，和备份片数量、磁盘 IO 匹配即可 allocate channel c1 device type disk; allocate channel c2 device type disk; allocate channel c3 device type disk; allocate channel c4 device type disk; # %b 保留原文件名，避免同名文件互相覆盖；目录要提前建好 set newname for database to '/u02/oradata/upgdb/datafile/%b'; # 恢复到某个时间点，给生产库留出继续写入的空间 set until time "to_date('2024-03-01:02:00:00','YYYY-MM-DD:HH24:MI:SS')"; restore database; release channel c1; release channel c2; release channel c3; release channel c4; }

SET NEWNAME FOR DATABASE TO ...%b里的%b是原文件名，如果不加这个占位符而写成固定路径，所有数据文件会往同一个文件上写，报错是ORA-01180: cannot create datafile，看着像权限问题，其实是重名。通道数不是越多越好，一般按备份片数量的一半给，给多了会把备份盘 IO 打满，反而更慢。

3.3 RMAN-06054 不是恢复失败，是归档断了

恢复做到一半，终端上出现这段：

RMAN-03002: failure of recover command at 03/01/2024 21:40:31 RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 25197 and starting SCN of 18157927920

这个报错的意思是：RMAN 已经把能应用的归档全应用完了，还差 sequence 25197 这一个，但它在备份目录里找不到。根因通常有三种——归档还没生成（生产库还没跑到那个 SCN）、归档生成了但没拷贝过来、归档拷贝过来了但没 catalog。

排查顺序固定：先确认备份目录里到底有什么，再看数据库当前还需要什么。

rman target / # 看最近一天备份进来的归档，确认最大序列号是多少 RMAN> list backup of archivelog from time 'sysdate-1'; # 看控制文件里已登记的归档范围 RMAN> list archivelog all; # 如果新拷了归档进来，重新扫一遍目录 RMAN> catalog start with '/backup/arch/';

如果生产库那边还在跑，最省事的做法就是等一会儿再拷一批归档过来，重新 catalog 后继续recover database。目标库只要没有以读写方式打开，就可以反复追归档，直到追到计划中的切换时间点。

这里有个反直觉的操作：追到一半想先看看数据对不对，可以用只读方式打开，但打开之后不能直接继续 recover，必须先关掉。

sqlplus / as sysdba # 只读打开，验证数据可用性，此时库不接受写入 SQL> alter database open read only; SQL> select count(*) from some_business_table; SQL> shutdown abort; # 回到 mount 状态才能继续追归档 SQL> startup mount;

shutdown abort在这里是正常操作，不是异常退出，不用担心。回到 mount 之后重跑recover database，把新拷来的归档应用上去，直到不再报RMAN-06054而是提示media recovery complete。那一刻才说明源库的数据在目标库上齐了，可以进 DBUA。

4. DBUA 执行阶段的报错：监听、时区、组件、密码

预检查过了，数据也恢复了，DBUA 跑到一半仍然会停。这一阶段的报错大多有明确的修复动作，难点在于知道该看哪一处配置。

4.1 ORA-12541 与 LOCAL_LISTENER：DBUA 连不上自己的库

DBUA 本质是个客户端，它要通过监听连到目标实例去做升级。目标库上新装的 19C 监听如果没配SID_LIST_LISTENER，或者实例的local_listener参数指向了源库的地址，DBUA 第一步就会报ORA-12541: TNS:no listener。

# 确认监听状态与注册的服务 lsnrctl status # 确认实例侧的注册参数 sqlplus / as sysdba SQL> show parameter local_listener SQL> show parameter service_names

lsnrctl status的输出里如果只有The listener supports no services，说明实例没注册上来。两种修法：静态注册（在listener.ora里加SID_LIST_LISTENER，重启监听）或者动态注册（把local_listener设成(ADDRESS=(PROTOCOL=TCP)(HOST=本机IP)(PORT=1521))，然后alter system register）。升级场景我一般用静态注册，因为它不依赖实例状态，DBUA 起停实例的过程中连接不会断。

注意：listener.ora里的ORACLE_HOME必须指向 19C 的 home，指向 11g 的 home 会让监听去拉 11g 的二进制，报错信息是一串看不懂的TNS-12518。

4.2 时区版本不够：DBMS_DST 与 DST 补丁

19C 要求时区文件版本达到 32 以上，11.2.0.4 的默认版本通常在 14 左右。这个检查在 DBUA 预检查里表现为一条 WARNING，很多人点「忽略」继续，结果升级完发现涉及TIMESTAMP WITH TIME ZONE的查询结果不对，或者物化视图刷新报错。

-- 源库上确认当前时区文件版本 select version from v$timezone_file; -- 看当前数据库的时区设置 select dbtimezone, sessiontimezone from dual;

处理方式有两条路：一是在源库上先应用 DST 补丁，把版本推上去再升；二是在 DBUA 里勾选「升级时区数据」，让升级过程顺带处理。后者省事但耗时长，大库上这一步可能跑几个小时，维护窗口要留够。

-- 升级完成后验证时区版本，19C 上应该 >= 32 select version from v$timezone_file; -- 检查有没有不受支持的时区版本记录 select * from v$timezone_file_supp;

如果dbtimezone是+00:00，说明用的是 UTC，风险最小；如果设成了具体地区（比如Asia/Shanghai），升级前一定要确认业务里的时区转换逻辑，别升完才发现报表时间整体偏移。

4.3 组件状态异常：OLAP、EXPRESS、XDB 该留还是该删

dba_registry里存在INVALID或LOADED状态的组件时，DBUA 会拒绝继续。这类报错通常写得很清楚，比如「component XDB is invalid」，但处理方式需要判断——有些组件根本不用，删掉比修复更省事。

-- 列出所有组件及其状态，重点看 STATUS 列 select comp_id, comp_name, version, status from dba_registry order by comp_id;

判断原则：OPTION类组件（OLAP、EXPRESS、Data Mining）如果业务不用，升级前直接drop掉，别想着「留着说不定以后用得上」，它们会在升级时制造一堆无效对象。XDB、JAVA这类组件如果状态是 INVALID，要先@?/rdbms/admin/catno...系列脚本重装或者utlrp重编译，不能带着 INVALID 状态升级。

-- 编译所有无效对象，升级前后各跑一次 @?/rdbms/admin/utlrp.sql -- 编译完再查一次，确认 INVALID 数量降下来了 select count(*) from dba_objects where status = 'INVALID';

utlrp.sql跑完还有大量 INVALID 的话，别急着往下走，先看是哪些对象——如果是业务自己的存储过程依赖了已删除的组件，得先把依赖关系理清，否则升级后应用连编译都过不去。

4.4 密码大小写敏感：19C 里 sec_case_sensitive_logon 已经没了

11g 时代很多人把sec_case_sensitive_logon设成FALSE，让登录不区分大小写，省去改应用的麻烦。19C 里这个参数被废弃，DBUA 升级时会把它剔除掉，结果是升级完成后一部分应用账号登录报ORA-01017: invalid username/password。

-- 源库上先看有多少账号的密码是大小写不敏感的 select username, account_status from dba_users where account_status = 'OPEN'; -- 检查参数当前值，TRUE 才符合 19C 的行为 show parameter sec_case_sensitive_logon;

处理动作要在升级窗口之前完成：把所有受影响的账号密码确认一遍，让应用侧改成大小写正确的写法。升级后再改就晚了，因为参数已经不存在，只能靠ALTER USER ... IDENTIFIED BY重设密码，而重设密码在生产上意味着要改配置、重启应用。

顺带一提，19C 默认密码过期策略也更严，PASSWORD_LIFE_TIME如果还是默认值，升级完 180 天内会集体过期。升级前把这个 profile 改掉，比事后救火轻松得多。

4.5 图形界面容易断：用静默模式跑 DBUA

DBUA 的图形界面依赖 X11 转发，网络一抖、SSH 一断，升级进程就跟着没了，而且没法从断点续跑。真正在生产环境执行时，用静默模式更可靠。

# 静默模式示例，参数以实际 home 路径和实例名为准 $ORACLE_HOME/bin/dbua -silent \ -sid UPGDB \ -oracleHome $ORACLE_HOME \ -reuseLogs false \ -upgradeTimezone true \ -parallel 4 \ -responseFile /home/oracle/dbua.rsp

-sid指定要升级的实例，-oracleHome是目标 19C 的 home，-upgradeTimezone决定要不要顺带处理时区数据，-parallel控制升级脚本的并行度。响应文件可以先跑一次图形界面生成出来，再拿去改，省得对着文档一个个猜参数名。静默模式的好处是日志会完整落到固定目录，断了能看出断在哪一步。

5. 常见问题与避坑：五条踩过的血泪记录

升级这种事，出问题的往往不是 DBUA 本身，而是周边那些「应该没问题」的环节。下面五条都是实际撞过的，按现象、原因、解决拆开写。

5.1 备份没验证过，恢复时才发现缺归档

现象：restore database跑到 80% 报RMAN-06026: some targets not found，或者ORA-19505: failed to identify file，一看是某个备份片根本不存在。

原因：备份脚本每天跑，但从来没人做过恢复演练。备份盘满过一次，脚本报错被 CRON 邮件淹了，缺了一天的备份集没人发现。

解决：升级前必须做一次restore validate，把整个备份链走一遍，不落盘只校验可读性。

rman target / # 校验数据库备份，只读备份片，不写数据文件，速度快 RMAN> restore database validate; # 单独校验归档，确认没有断号 RMAN> restore archivelog all validate;

校验通过再动手。这一步花二十分钟，能省掉升级当天最难受的几个小时。

5.2 环境变量串台：DBUA 用的是上一个 shell 的 home

现象：DBUA 启动后报找不到实例，或者报ORA-01034: ORACLE not available，但手工sqlplus连得好好的。

原因：同一个终端窗口里先后export过 11g 和 19C 两套环境变量，ORACLE_HOME被后一次覆盖，PATH里还留着旧 home 的 bin 目录，dbua这个命令其实来自 19C，但它继承的环境是 11g 的。

解决：每个操作开独立 shell，执行前先把变量打出来确认。

# 动手之前先自检，三个变量都必须是目标 home echo $ORACLE_HOME echo $ORACLE_BASE echo $ORACLE_SID which dbua # 建议在脚本里加一道断言，路径不对就直接退出 [ "$ORACLE_HOME" = "/u01/app/oracle/product/19.0.0/dbhome_1" ] || { echo "home 不对"; exit 1; }

5.3 快速恢复区被写满，升级跑到一半挂住

现象：升级脚本执行到一半，实例 hang 住，告警日志里刷ORA-19809: limit exceeded for recovery files和ORA-19804: cannot reclaim ... bytes disk space。

原因：升级过程中会生成大量 redo 和归档，db_recovery_file_dest_size还是源库那个值，目标库磁盘又比源库小，很快就顶到上限。

解决：升级前把恢复区上限调大，或者干脆换到独立的大盘上。

-- 先看当前用量和上限 select * from v$recovery_file_dest; select * from v$recovery_area_usage; -- 上限调到实际磁盘的 70% 左右，别设成满盘 alter system set db_recovery_file_dest_size = 200G scope = both;

同时把归档备份脚本停掉，升级窗口内别让定时任务来抢空间。

5.4 升级完没收集字典统计，第二天全是慢查询

现象：升级后应用能连上，但几个核心报表从 20 分钟变成 2 小时，执行计划全变了。

原因：19C 优化器对字典统计信息依赖更重，升级过程不会自动收集系统表的统计信息，dba_tab_col_statistics里还是 11g 时期的旧数据，优化器估错行数。

解决：升级完成后立刻收一遍字典统计，再跑一次固定 SQL 的性能基线。

-- 收集字典统计，耗时较长，放在维护窗口内做 exec dbms_stats.gather_dictionary_stats; -- 收集固定对象的统计，这个必须有，否则 SYS 下的执行计划会飘 exec dbms_stats.gather_fixed_objects_stats; -- 刷新一次游标，让新统计生效 alter system flush shared_pool;

5.5 急着把 11g 的 home 删了，回退时没路可走

现象：升级完成后第三天发现某个关键功能异常，想回退，发现 11g 的ORACLE_HOME已经被清理，只剩数据文件，回不去。

原因：升级完成后磁盘告急，顺手把旧 home 删了。回退不只是把数据文件挂回去，还需要对应版本的二进制、监听配置和oratab条目。

解决：旧 home 至少保留到业务验证完整跑过一轮，通常是一个完整的月结周期。删之前先确认三件事：19C 上所有功能验证通过、没有遗留的兼容性问题、回退方案已经不再需要。

# 旧 home 保留期间，确认它还在 oratab 里，方便随时切回 cat /etc/oratab # 真要清理时，先打包留档，别直接 rm tar -czf /backup/old_home_11g.tar.gz /u01/app/oracle/product/11.2.0/dbhome_1

6. 快速定位：升级卡住时先看哪三份东西

DBUA 出问题的时候，最忌讳的是打开图形界面反复点重试。它每次重试都会覆盖日志，越点信息越少。正确的做法是停下来，按固定顺序看三份材料，基本能在十分钟内定位到方向。

第一份是源库上的preupgrade.log。绝大多数「升级到一半莫名其妙失败」的问题，答案早就写在这份报告里了，只是当时被当成 WARNING 忽略了。搜ERROR和WARNING两个关键词，把带fixup字样的条目挑出来逐条对照。

第二份是 DBUA 的日志目录，位置随版本略有差异，一般在这个路径下：

# 按时间排序，最新的一次升级在最上面 ls -lt $ORACLE_BASE/cfgtoollogs/dbua/upgdb/ # 找报错关键词，比逐页翻快得多 grep -iE "ORA-|RMAN-|error|failed" $ORACLE_BASE/cfgtoollogs/dbua/upgdb/upgrade*/upgrade*.log | head -50

第三份是目标库的告警日志和升级脚本日志。升级过程中catupgrd.sql的产出会单独落一份，里面记录每个组件脚本的执行结果，组件级失败只能在这里看到。

按症状查表更快：

还有两个常被忽略的验证点。一是升级是不是真的做完了，不要只看 DBUA 的提示，查dba_registry里所有组件的STATUS是否都是VALID，再查dba_registry_sqlpatch确认补丁记录与目标版本一致。二是升级后的实例参数有没有被悄悄改掉，v$parameter里compatible、optimizer_features_enable、sec_case_sensitive_logon这几个值都值得逐个核对一遍。

从那以后我每次做升级，无论多紧急，都强制走一遍「validate 备份、跑 preupgrade 脚本、确认三个环境变量」这三步，一步不落。翻车的代价从来不是那二十分钟的准备时间，而是升级窗口结束前半小时发现要回退、却回退不了的绝望。希望帮到你。

本文还有配套的精品资源，点击获取