简介：这份Oracle 11g到19C数据库升级详尽指导手册，面向具备一定运维能力的数据库管理员（DBA）及运维工程师，聚焦利用DBUA工具将11g单机数据库安全迁移至19C的完整流程。内容涵盖前期备份与恢复、升级路线选择、环境说明、参数文件恢复、归档追平等关键环节，并强调检查脚本日志与警告等注意事项，同时附有多个故障解决方案应对升级异常。资源包共1个PDF文件，大小约3.18MB，以图文与命令示例结合的方式呈现，便于按步骤对照操作。目前已有1350人学习下载，适合需要系统掌握DBUA升级方法、提升数据库性能与安全性的中高级运维人员参考。

1. 升级卡在 DBUA 第一步：为什么 11g 到 19C 的坑总在“看起来没问题”时爆发

如果你正在搜“Oracle 11g 升级 19C 报错怎么办”“DBUA 升级失败怎么解决”，大概率已经卡在某个环节了。11g 早已停止补丁更新，官方建议迁到 19C，但真正动手才发现：DBUA 图形界面点下去容易，背后从操作系统版本、升级路线、RMAN 恢复到时区文件，每一步都可能翻车。我见过太多案例，升级窗口只有几小时，结果卡在RMAN-06054或 DBUA 预检查报错上，回退都来不及。这篇笔记面向正在做 11g 单机升 19C 的 DBA 和运维，把 DBUA 升级中最常见的几类故障拆开：现象是什么、根因在哪、怎么用命令解决、以后怎么提前避开。照着做，新手能复现，熟手能看清排查逻辑。

2. 升级前就翻车：RMAN 恢复报错与 DBUA 预检查不通过

2.1 RMAN-06054：恢复时找不到归档日志，时间点追不上

这是升级准备阶段最高频的报错。你从生产库备份恢复到目标库，执行RECOVER DATABASE时突然报：

RMAN-03002: failure of recover command RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 25197 and starting SCN of 18157927920

现象很明确：RMAN 需要 sequence 25197 的归档，但/hisbak/目录里没有。根因通常有两个——要么备份时归档没传全，要么你SET UNTIL TIME设的时间点晚于现有归档的最后 SCN。先别急着重新恢复，用下面命令确认归档边界：

# 进入 RMAN，列出最近一天的归档备份 rman target / RMAN> list backup of archivelog from time 'sysdate-1';

输出里重点看Low SCN、Next SCN和Sequence。如果最大 sequence 是 25196，而报错要 25197，说明归档确实缺了。解决办法：从源库把缺失的归档拷贝到/hisbak/，然后重新catalog start with '/hisbak/';再RECOVER DATABASE。如果源库归档已删除，只能把恢复时间点往前调，用SET UNTIL TIME卡在已有归档覆盖的范围内。

提示：恢复阶段不要急着open read only，先确认REPORT SCHEMA里数据文件路径和control_files一致，否则后面 DBUA 会报更隐蔽的错。

2.2 DBUA 预检查失败：时区版本和组件无效对象

DBUA 启动后第一个大关是预检查。常见报错是“Timezone version is lower than required”或“Invalid objects in SYS/SYSTEM”。根因是 11g 的时区文件版本太老，19C 要求至少 version 32；另外 11g 里长期没编译的无效对象会被 19C 的utlrp.sql暴露出来。

先查时区版本：

-- 在源库 11g 上执行 SELECT version FROM v$timezone_file;

如果低于 32，用DBMS_DST包升级时区文件，或者直接打对应补丁。无效对象用下面语句统计：

SELECT owner, object_type, COUNT(*) FROM dba_objects WHERE status = 'INVALID' GROUP BY owner, object_type ORDER BY 3 DESC;

如果 SYS/SYSTEM 下无效对象超过 10 个，先在源库跑@?/rdbms/admin/utlrp.sql重编译，再重新生成 DBUA 预检查。注意：预检查日志在$ORACLE_BASE/cfgtoollogs/dbua/下，每次失败都要翻到具体条目，别只看界面上的红叉。

2.3 操作系统版本不满足：Linux 6 上装不了 19C

19C 对操作系统最低要求是 Linux 7。如果你的 11g 跑在 Linux 6 上，DBUA 根本不会让你继续。现象是安装 19C 软件时直接报“Unsupported OS version”。根因不是数据库问题，是主机版本。解决办法只有一条：准备一台 Linux 7 的新主机，装好 19C 软件，再把 11g 的备份恢复到新主机上做升级。别想着在 Linux 6 上硬装，后面即使绕过检查，运行期也会出各种链接库错误。

# 在新主机上确认 OS 版本 cat /etc/redhat-release # 输出应为 Red Hat Enterprise Linux Server release 7.x

注意：源库保留不动，目标库用新主机，这样升级失败还能回退到生产。这是最稳妥的路径。

3. DBUA 执行中报错：从 mount 到 open 的典型故障

3.1 ORA-01092 / ORA-00704：升级后打开数据库失败

DBUA 跑到最后一步startup upgrade之后，经常报：

ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00704: bootstrap process failure

根因通常是compatible参数没改，或者undo_tablespace指向了不存在的 UNDO。19C 要求compatible至少为11.2.0.4，但升级后应设为19.0.0。检查参数文件：

-- 在 mount 状态下查看 SHOW PARAMETER compatible; SHOW PARAMETER undo_tablespace;

如果compatible还是11.2.0.4.0，用下面命令改：

ALTER SYSTEM SET compatible='19.0.0' SCOPE=SPFILE; SHUTDOWN IMMEDIATE; STARTUP UPGRADE;

然后重新跑@?/rdbms/admin/catupgrd.sql。如果undo_tablespace指向的 UNDO 表空间在恢复时没建出来，先创建再改参数。

3.2 DBUA 卡在 90%：utlrp.sql 编译无效对象超时

DBUA 进度条到 90% 左右不动，日志里反复出现Compiling invalid objects。根因是 11g 遗留的无效对象太多，utlrp.sql单线程编译耗时极长。解决办法是手动介入：

-- 先查剩余无效对象数量 SELECT COUNT(*) FROM dba_objects WHERE status='INVALID'; -- 如果数量在减少但很慢，开并行编译 ALTER SESSION SET parallel_max_servers=8; @?/rdbms/admin/utlrp.sql

如果数量长时间不变，说明有对象编译报错。查dba_errors：

SELECT owner, name, type, text FROM dba_errors WHERE owner NOT IN ('SYS','SYSTEM') ORDER BY owner, type;

常见原因是自定义 Java 存储过程或旧版 PL/SQL 包引用了 19C 已移除的包。这类对象要么改代码，要么在升级前就标记为无效并排除。

3.3 ORA-39405：时区文件版本不匹配导致数据泵导入失败

如果你在升级后做数据泵导入，可能遇到：

ORA-39405: Oracle Data Pump does not support importing from a source database with TZ version 18 to a target database with TZ version 32

根因是源库时区版本低于目标库。解决办法是在源库先升级时区文件，或者导入时加DISABLE_TZ_CHECK参数（仅限测试环境）。生产环境建议在升级前统一时区版本：

-- 源库执行，检查当前时区版本 SELECT version FROM v$timezone_file; -- 如果低于 32，用 DBMS_DST 升级 EXEC DBMS_DST.BEGIN_PREPARE(32); -- 后续按 MOS 文档完成升级

提示：时区升级是不可逆操作，务必先在测试库验证。

4. 升级后验证：那些“看起来成功”却埋雷的检查项

4.1 组件状态和无效对象复查

DBUA 显示成功不代表真的干净。升级后必须查dba_registry：

SELECT comp_id, comp_name, version, status FROM dba_registry ORDER BY comp_id;

所有组件status应为VALID。如果有INVALID或OPTION OFF，比如JAVAVM或XDB，需要单独跑对应脚本重装。常见的是ORACLE_APEX版本不兼容，19C 自带 APEX 版本高于 11g，升级后要按 APEX 官方步骤迁移。

4.2 时区版本和归档模式确认

升级后再次确认时区版本：

SELECT version FROM v$timezone_file; -- 19C 应为 32 或更高

同时确认归档模式是否保持：

ARCHIVE LOG LIST; -- 应显示 Database log mode: Archive Mode

如果升级过程中db_recovery_file_dest_size没调够，归档可能写失败，导致后续备份报错。检查：

SHOW PARAMETER db_recovery_file_dest_size; -- 建议至少 200G，视业务量调整

4.3 监听和 service_names 注册

升级后客户端连不上，先看监听：

lsnrctl status

如果bsoftsb服务没注册，检查service_names参数：

SHOW PARAMETER service_names; -- 应包含升级后的 db_unique_name

必要时手动注册：

ALTER SYSTEM REGISTER;

然后从客户端用tnsping和sqlplus验证连接。

5. 避坑记录：升级 11g 到 19C 最容易踩的 5 个坑

坑 1：恢复时用SET UNTIL TIME追到未来时间现象：RMAN-06054报找不到归档。 原因：时间点设得比现有归档最后 SCN 还晚。 解决：先用list backup of archivelog确认最大 sequence 和 SCN，再把SET UNTIL TIME调到覆盖范围内。

坑 2：DBUA 预检查忽略时区版本现象：预检查报时区版本低，强行跳过。 原因：19C 要求 TZ version 32，11g 默认 18 或更低。 解决：升级前在源库用DBMS_DST升级时区，或打对应补丁，别跳过。

坑 3：Linux 6 上硬装 19C现象：安装软件时报 OS 不支持。 原因：19C 最低要求 Linux 7。 解决：准备新主机，源库保留，目标库用 Linux 7 恢复升级。

坑 4：升级后没跑utlrp.sql就开放业务现象：业务查询报ORA-04063或ORA-06508。 原因：无效 PL/SQL 对象未编译。 解决：升级后必须跑@?/rdbms/admin/utlrp.sql，并查dba_errors清零。

坑 5：忘记改compatible参数现象：startup upgrade后报ORA-00704。 原因：compatible还是 11g 的值。 解决：在 mount 状态改compatible='19.0.0'，再startup upgrade重跑升级脚本。

6. 快速定位升级故障：我的排查顺序和验证习惯

每次 11g 升 19C 出问题，我按固定顺序排查，基本能在 10 分钟内定位到根因。第一步，看 DBUA 日志目录$ORACLE_BASE/cfgtoollogs/dbua/，找到最新一次运行的*_log.txt，搜ERROR和ORA-。第二步，如果 DBUA 还没启动就报错，直接查源库的dba_registry和v$timezone_file，这两个是预检查的核心。第三步，RMAN 恢复阶段报错，先list backup of archivelog确认归档边界，再决定是补归档还是调时间点。第四步，升级后打不开，查alert log里的ORA-错误，重点看compatible和undo_tablespace。第五步，升级后业务报错，查dba_objects无效对象和dba_errors。

下面这张表是我常用的报错对照，贴在工位上随时查：

验证习惯上，我坚持三条：升级前在测试库完整走一遍 DBUA，记录每步耗时和报错；升级后先跑utlrp.sql再查dba_registry，确认所有组件 VALID；最后用业务账号跑一遍核心查询，别只用 SYS 测。从那以后我每次升级前都强制走一遍“时区版本 + 无效对象 + OS 版本”三查，再也没在 DBUA 预检查上翻过车。希望帮到你。

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