企业官网建设流程全解析

简介：这份《Oracle 11g 到 19C 数据库升级详尽指导手册》面向具备一定运维能力的数据库管理员（DBA），聚焦于使用 DBUA（Database Upgrade Assistant）工具将 Oracle 11g 安全迁移至 19C 的完整流程。内容涵盖前期备份与恢复、升级路线选择、环境说明、参数文件恢复、归档追平等关键环节，并强调检查脚本日志与警告等注意事项，同时附有多个故障解决方案，帮助应对升级中的异常情形。资源包为 1 个 PDF 文件，大小约 3.18MB，结构紧凑，便于按章节查阅。目前已有 1350 人学习下载，适合希望通过 DBUA 提升数据库性能与安全性、符合未来软件架构趋势的运维人员参考，尤其对命令细节和操作顺序要求严谨的读者价值较高。

1. 从 11g 到 19c：为什么 DBUA 是单机升级最稳的那条路

手上还跑着 11.2.0.4 的库，补丁早停了，官方支持也到期了，安全扫描每次都能扫出一堆 CVE。升级到 19c 这件事，拖得越久越被动。但真到动手的时候，DBA 面前通常摆着两条路：手动升级（Manual Upgrade）和 DBUA（Database Upgrade Assistant）。手动升级可控性最强，但步骤多、依赖顺序严、容易漏脚本；DBUA 把 precheck、升级、postcheck 串成一条流水线，图形界面加静默模式都能跑，对单机升级场景来说，是性价比最高的选择。

这份手册围绕的就是一个具体场景：11g 单机通过 DBUA 升级到 19c。它不讲理论发展史，直接给环境说明、备份恢复、DBUA 执行、日志排查的完整链路。适合有一定 RMAN 基础、手上有生产库要迁的运维人员。如果你正在搜「Oracle 19C DBUA 升级步骤」「11g 升级 19c 踩坑」，这篇就是照着那个思路拆的。

2. 升级前的硬性条件：版本路线、主机要求与备份恢复链路

2.1 先确认你的版本能不能直连 19c

Oracle 的升级路线不是随便跳的。19c 支持的直接升级路径只有下面这几种：

所以第一步不是打开 DBUA，而是select version from v$instance;确认源库到底是不是 11.2.0.4。如果是 11.2.0.3 甚至更早，先老老实实打补丁到 11.2.0.4，别想着绕。

2.2 主机操作系统这关最容易翻车

19c 对操作系统的最低要求是 Linux 7。如果源库跑在 Linux 6 上，DBUA 根本不会让你往下走。常见做法是准备一台新主机装 Linux 7，把 19c 软件装好，再通过 RMAN 把生产库恢复到新主机上做升级。原生产库保留不动，升级失败还能回退。

注意：不要在原生产主机上直接装 19c 然后原地升级，除非你确认 OS 版本达标且有完整回退方案。生产库原地升级翻车后恢复时间不可控。

2.3 用 RMAN 把生产库恢复到升级环境

升级环境准备好之后，核心动作是把生产库的备份恢复过来。手册里给的是完整链路，我按实际操作顺序拆一下。

恢复参数文件：

# 启动到 nomount，从备份中恢复 spfile rman target / RMAN> startup nomount; RMAN> restore spfile from '/hisbak/spfile_BSOFT_562120512_20220830_40444.ora'; # 从 spfile 生成 pfile，方便手工调整参数 SQL> create pfile='/home/oracle/pfile.ora' from spfile;

生成 pfile 之后，需要根据目标环境改几个关键参数：audit_file_dest、control_files、db_recovery_file_dest、db_unique_name、diagnostic_dest这些路径类的必须改，memory_target、sga_target、pga_aggregate_target根据新主机内存调整。改完用 pfile 启动再重建 spfile：

SQL> startup nomount pfile='/home/oracle/pfile.ora'; SQL> CREATE SPFILE='/u02/app/oracle/product/11.2.0/db/dbs/spfilebsoft.ora' FROM PFILE='/home/oracle/pfile.ora';

恢复控制文件并加载备份：

RMAN> restore controlfile from '/hisbak/BSOFT_CONT_562120512_20220830_40443.ctl'; RMAN> sql 'alter database mount'; RMAN> catalog start with '/hisbak/';

catalog start with这步是把备份目录里的所有备份片注册到控制文件里，不然后面restore database找不到备份集。跑完之后用REPORT SCHEMA确认数据文件列表是否完整。

Restore 和 Recover 分步走：

# Restore 到指定时间点 run { ALLOCATE CHANNEL C1 DEVICE TYPE DISK; -- ... 省略 C2 到 C15 ... ALLOCATE CHANNEL C16 DEVICE TYPE DISK; SET NEWNAME FOR DATABASE TO '/oradata/BSOFTSB/datafile/%b'; SET UNTIL TIME "TO_DATE('2022-08-30:02:00:00', 'YYYY-MM-DD:HH24:MI:SS')"; RESTORE DATABASE; RELEASE CHANNEL C16; -- ... 省略释放 C15 到 C2 ... RELEASE CHANNEL C1; }

SET NEWNAME把数据文件重定向到新路径，SET UNTIL TIME控制恢复的时间点。Restore 完成后执行SWITCH DATABASE TO COPY让控制文件指向新位置，然后分多次RECOVER DATABASE逐步往前追归档。手册里分了 02:00、07:00、12:00 三个时间点推进，每次追完可以alter database open read only验证数据，确认没问题再关掉继续追。

注意：每次重新追归档前必须shutdown abort; startup mount;，因为 read only 模式下不能做恢复。这个顺序搞反了会报 ORA-16000。

3. DBUA 执行升级：从 precheck 到 postcheck 的完整流程

3.1 升级前的检查清单

DBUA 启动之前，有几件事必须手工确认，不然 precheck 阶段就会卡住：

• 源库不能有活跃的 XDB 或 OLAP：11g 里如果装了 XDB 组件，升级到 19c 时 DBUA 会报错。常见做法是升级前先drop掉不用的组件，或者确认 19c 仍然支持。
• 时区文件版本：11g 的时区文件版本如果太老，19c 的 precheck 会提示需要先升级时区。用select version from v$timezone_file;查，低于 14 的建议先打补丁。
• 无效对象和重复对象：utlrp.sql先跑一遍，把无效对象数量降下来。重复对象用utlvalid.sql检查。
• 归档空间：升级过程中会产生大量归档，db_recovery_file_dest_size至少留 50G 以上余量。
• 备份：升级前做一次全备，包括归档。这是后悔药，别省。

3.2 启动 DBUA 并走完图形界面

19c 的 DBUA 在$ORACLE_HOME/bin/dbua。以 oracle 用户执行：

export ORACLE_HOME=/u02/app/oracle/product/19.14.0/db_1 export PATH=$ORACLE_HOME/bin:$PATH dbua

图形界面会依次让你选源库、确认升级类型、配置参数。几个关键选择：

• 升级类型：选「Upgrade Oracle Database」而不是「Move Database」。单机升级不需要搬库。
• 并行度：默认 1 就行，生产库升级不建议开高并行，容易把 I/O 打满。
• 恢复选项：DBUA 会问要不要开 Flashback。如果空间够，建议开，升级失败可以闪回。
• 网络配置：监听端口和 service name 确认一下，别跟源库冲突。

3.3 静默模式：批量升级的省事方案

如果不想开图形界面，DBUA 支持静默模式。先准备一个响应文件，然后：

dbua -silent -responseFile /home/oracle/dbua_response.rsp

响应文件里至少要配这几个参数：

静默模式跑完之后，日志在$ORACLE_BASE/cfgtoollogs/dbua/下面，按 SID 和时间戳分目录。

3.4 升级后的验证动作

DBUA 跑完不代表万事大吉。升级后必须做这几件事：

-- 确认版本 SQL> select version from v$instance; -- 确认组件状态 SQL> select comp_name, status from dba_registry; -- 跑一遍无效对象编译 SQL> @?/rdbms/admin/utlrp.sql -- 检查时区文件版本 SQL> select version from v$timezone_file;

dba_registry里所有组件的 status 应该是VALID。如果有INVALID的，看 DBUA 日志里对应的错误，通常是某个组件在 19c 里被废弃了，需要手工处理。

4. 避坑与排查：升级过程中最容易翻车的五个点

4.1 ORA-06054：media recovery requesting unknown archived log

现象：RECOVER DATABASE时报RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 25197。

原因：归档日志链断了，RMAN 需要 sequence 25197 的归档，但备份目录里没有。

解决：先list backup of archivelog from time 'sysdate-1';看手上有哪些归档。如果确实缺，从生产库把对应的归档拷过来，catalog之后继续recover。如果生产库也删了，只能恢复到最后一个可用归档的时间点，接受数据丢失。

4.2 DBUA precheck 报时区版本不匹配

现象：precheck 阶段提示Timezone version is lower than required。

原因：11g 的时区文件版本低于 19c 要求的最低版本（通常是 14 或更高）。

解决：在源库上先打时区补丁。用select version from v$timezone_file;确认当前版本，然后从 MOS 下载对应的时区补丁包，按 README 执行。打完重启库再跑 DBUA。

4.3 升级后监听起不来

现象：DBUA 跑完，lsnrctl start报错，或者客户端连不上。

原因：19c 的监听配置和 11g 不兼容，listener.ora里的SID_LIST_LISTENER需要改成SID_LIST格式，或者直接用动态注册。

解决：检查$ORACLE_HOME/network/admin/listener.ora，把旧的静态注册段删掉，让 PMON 动态注册。alter system register;手动触发一次注册，然后lsnrctl status确认 service 已经注册上。

4.4 升级后 SQL 执行计划突变

现象：升级到 19c 后，原来跑得很快的 SQL 突然变慢，执行计划从索引扫描变成全表扫描。

原因：19c 的优化器行为跟 11g 有差异，尤其是自适应游标共享和 SQL 计划管理这块。

解决：用 SQL Plan Baseline 把 11g 的好计划固定住。升级前从 11g 的dba_sql_plan_baselines导出，升级后导入到 19c。或者用SQLT做计划对比，找出差异大的 SQL 逐个调。

4.5 DBUA 中途失败，库处于中间状态

现象：DBUA 跑到一半报错退出，数据库既不是 11g 也不是 19c 状态。

原因：升级过程中某个脚本执行失败，DBUA 没有自动回滚。

解决：先看$ORACLE_BASE/cfgtoollogs/dbua/<SID>/下的日志，找到具体失败的脚本。如果是catupgrd.sql里的某一步，可以手工执行那个脚本再继续。如果状态太乱，直接用升级前的全备恢复，重新来一遍。这就是为什么升级前必须做全备。

5. 升级后的收尾技巧：从 read only 验证到生产切换

升级完成后，别急着把生产流量切过来。我一般会走一遍「read only 验证 → 应用兼容性测试 → 正式切换」的流程。

第一步，read only 打开验证数据。DBUA 跑完后，数据库默认是 open 状态。但为了保险，可以先shutdown immediate; startup mount; alter database open read only;，让应用连上来跑几个关键查询，确认数据没问题。read only 模式下不能写，但读没问题。

第二步，跑一遍应用兼容性测试。把生产上最核心的几条 SQL 和存储过程在 19c 上跑一遍，对比结果和 11g 是否一致。特别注意ROWNUM、CONNECT BY、DECODE这些在 19c 里行为有微调的地方。

第三步，正式切换。确认没问题后，shutdown immediate; startup;正常打开，然后把监听配置切到 19c 的 ORACLE_HOME，应用连接串改到新库。原 11g 生产库保留至少一周，确认 19c 稳定后再下线。

提示：切换前把 19c 的compatible参数确认一下。如果还是11.2.0.4.0，升级后可以改成19.0.0，但改之前必须确认所有应用都兼容 19c 的新特性。改compatible是不可逆的，改完就不能降回去了。

从那以后我每次做升级，都会在 DBUA 跑之前强制走一遍「版本确认 → 时区检查 → 无效对象编译 → 全备」这四步，少一步都不敢点下一步。希望帮到你。

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