简介这份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 上装不了 19C19C 对操作系统最低要求是 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 compatible19.0.0 SCOPESPFILE; 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 statusINVALID; -- 如果数量在减少但很慢开并行编译 ALTER SESSION SET parallel_max_servers8; ?/rdbms/admin/utlrp.sql如果数量长时间不变说明有对象编译报错。查dba_errorsSELECT 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_registrySELECT 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调到覆盖范围内。坑 2DBUA 预检查忽略时区版本现象预检查报时区版本低强行跳过。 原因19C 要求 TZ version 3211g 默认 18 或更低。 解决升级前在源库用DBMS_DST升级时区或打对应补丁别跳过。坑 3Linux 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 状态改compatible19.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。下面这张表是我常用的报错对照贴在工位上随时查报错最可能根因第一命令RMAN-06054归档缺失或时间点超界list backup of archivelog from time sysdate-1;ORA-01092compatible 未改或 UNDO 缺失SHOW PARAMETER compatible;ORA-39405时区版本不匹配SELECT version FROM v$timezone_file;ORA-04063无效对象未编译SELECT COUNT(*) FROM dba_objects WHERE statusINVALID;DBUA 预检查失败时区/无效对象/OS 版本查cfgtoollogs/dbua/日志验证习惯上我坚持三条升级前在测试库完整走一遍 DBUA记录每步耗时和报错升级后先跑utlrp.sql再查dba_registry确认所有组件 VALID最后用业务账号跑一遍核心查询别只用 SYS 测。从那以后我每次升级前都强制走一遍“时区版本 无效对象 OS 版本”三查再也没在 DBUA 预检查上翻过车。希望帮到你。本文还有配套的精品资源点击获取