企业官网建设流程全解析

简介：《Oracle 11g 到 19C 数据库升级详尽指导手册》以 DBUA 工具为主线，面向具备一定运维经验的 DBA，解决 Oracle 11g 停止官方补丁更新后的安全迁移问题，目标是帮助企业在升级后提升性能与安全性，并顺应技术架构演进。手册按严格顺序拆解升级流程：前期备份与恢复、具体执行步骤、必要配置调整，并特别提醒检查脚本生成的日志和警告；针对升级中可能出现的异常，还提供了多种故障解决方案。内容同时梳理了直接与间接升级路径、源生产库与目标库的环境对照、RMAN 恢复参数文件等实操细节，参考官方 MOS 文档整理操作提醒，可作为 DBA 在真实迁移前的重要清单与排错备查。资源包含 1 个 PDF 文件，压缩包大小约 3.18MB，便于离线查阅。目前已有 1342 人学习下载，是值得收藏的 Oracle 升级实战参考。

1. 11g 退役之后，19C 升级这条路怎么走才不翻车

Oracle 11g 停止补丁更新后，整个行业都在往 19C 迁移。原因很直接：19C 是长期支持版本（Long Term Support），补丁和修复会持续到 2026 年之后，而 11g 从 2020 年 12 月起就不再收到任何季度补丁了。手里还跑着 11.2.0.4 的单机库，DBA 面临的不再是「要不要升」而是「怎么升才稳」。本文讲的是一条被验证过的实操路线：先用 RMAN 把生产库备份恢复到一台同版本的新环境，再在这台新环境上用 DBUA（Database Upgrade Assistant）从 11.2.0.4 升到 19.14。关键点是全程不动生产库，失败还能回退；而这篇手册恰好记录了这条路上所有容易踩的坑——从 pfile 路径、ASM 转文件系统，到追归档时报 RMAN-06054，每一条都是真实环境里碰过的。适合有 11g 运维经验、正准备规划 19C 升级路径的 DBA 和运维工程师。

2. 升级路线与恢复方案选型：直接升还是先过渡，目标库怎么搭

2.1 官方升级路线：11.2.0.4 是分水岭

19C 的升级路线有两条：直接升级和间接升级。官方支持矩阵里写得很清楚，11.2.0.4 及以上版本可以直接升到 19.x，所以 11.2.0.4 是这条路上的分水岭。如果你手里是 11.2.0.4，恭喜，DBUA 一条路走到底就行。但如果是 11.2.0.1、11.2.0.2、11.2.0.3，或者更早的 10g、9i，就必须先升到 11.2.0.4 这个中间站，再往 19C 走。11.1.0.6、11.1.0.7 同理，要先到 11.2.0.4。12.1.0.1 则是先升到 12.1.0.2 或 12.2.0.1，然后再继续。9.2.0.8 及更早版本，唯一路径是 11.2.0.4。这条线建议升级前先对着官方文档确认清楚，因为选错了路线，后面的工时和风险都要翻倍。

另一个容易忽视的点是操作系统。官方对 19C 的最低系统要求是 Linux 7，如果生产库跑在 Linux 6 上，那就没有省事的办法——必须准备一台新主机，装好 Linux 7，再把数据库迁过去。11g 时期很多库还跑在老旧内核上，这一条直接决定了整个项目的硬件规划和工期预算。

2.2 为什么先把生产库恢复到目标环境，而不是直接动生产

这本手册的核心思路，也是我一直推荐的思路：升级动作不直接发生在生产库上，而是先做一次完整的 RMAN 备份恢复，把生产环境克隆到一台全新的 19C 环境里，再在克隆环境上执行升级。好处显而易见——生产库全程只做备份和归档，不做任何变更，升级失败、配置出错、跑了一半想停，生产环境毫发无损，随时可以回退。

具体环境是这样的：源库是生产库，跑 11.2.0.4；目标库是一台 RHEL 7.9 的新主机，上面装了两个 ORACLE_HOME——11g 的实例存在/u02/app/oracle/product/11.2.0/db这个 ORACLE_HOME 下，19C 的 ORACLE_HOME 则放在/u01/app/oracle/product/19.14.0/db_1。恢复阶段先用 11g 的二进制把克隆库拉起来，让它以 11.2.0.4 的身份工作，DBUA 再把实例从 11g 的 ORACLE_HOME 切到 19C 的 ORACLE_HOME。两个 HOME 互不干扰，这比在同一个 HOME 里做 in-place 升级安全得多。

备份恢复还有一个额外的优势：时间点可以自己做主。先恢复到某个基础时间点，然后通过连续追归档把数据库推进到更接近当前的时间点，而生产库继续正常写入，互不影响。手册里就是这么操作的——先恢复到 2022-08-30 02:00，再追到 07:00，再到 12:00，最后一路追到备份集里能到达的最远位置。

2.3 目标库初始化参数：先让 11g 在 19C 环境里活下来

恢复到目标库后，第一件事不是急着升级，而是让这个克隆库在一个合理且可管理的参数环境下跑起来。手册里的 pfile 是手工整理过的，我挑几个关键的拆一下。*.compatible='11.2.0.4.0'是恢复阶段必须保留的——控制文件和数据文件都来自 11g，初期不能把 compatible 改大，DBUA 在升级过程中会自动调整这个参数，不用提前动。*.db_unique_name='bsoftsb'和*.db_name='bsoft'是故意区分开的：库名保持和生产一致，唯一名加后缀 sb，这样同一主机上即使未来出现多个库也不会混乱。

路径类参数是这次调整的重点。源库数据文件在 ASM+DATA上，目标环境没有 ASM，所以要全部改成文件系统路径。*.control_files='/oradata/bsoftsb/controlfile/control01.dbf'、*.db_create_file_dest='/oradata'。这里有个细节：restore 数据文件时用了SET NEWNAME FOR DATABASE TO '/oradata/BSOFTSB/datafile/%b'，%b是备份片里的原始文件名，这样可以保证 restoe 出来的文件按表空间原样落地，不会因为路径改写而丢失文件层级关系。

内存参数直接照搬生产环境不是一个好习惯。手册里*.memory_max_target和*.memory_target都是 128G，*.sga_target64G，*.pga_aggregate_target约 7.9G。这是生产规格，目标机如果内存不够，这里必须手动下调，否则实例起不来。我的做法是先按源库的 80% 预配，数据库能正常启动后再逐步调回。*.undo_retention=432000是 5 天，这个值对升级本身没有直接影响，但长时间追归档、反复 OPEN RESETLOGS 时，足够长的 undo 保留期能减少 ORA-01555 的出现概率。

# 恢复 spfile 后，先用 pfile 方式启动，修改参数 SQL> CREATE PFILE='/home/oracle/pfile.ora' FROM SPFILE; SQL> exit # 关键参数确认 vim /home/oracle/pfile.ora # *.compatible 保持 '11.2.0.4.0' # *.control_files 指向文件系统，不用 ASM # *.db_create_file_dest='/oradata' # *.memory_target 按目标机实际内存调整 # 用 pfile 启动实例 SQL> STARTUP NOMOUNT PFILE='/home/oracle/pfile.ora'; # 把修正后的参数固化到 spfile CREATE SPFILE='/u02/app/oracle/product/11.2.0/db/dbs/spfilebsoft.ora' FROM PFILE='/home/oracle/pfile.ora';

这一段的核心逻辑是：pfile 是恢复阶段的临时手段，等所有路径和参数确认无误后，再生成 spfile 固化。注意CREATE SPFILE时要显式指定 11g HOME 下的 dbs 目录路径，因为目标机上存在两个 ORACLE_HOME，不指定的话 spfile 可能落错位置，实例找不到参数文件。

3. RMAN 恢复实战：从控制文件到数据文件，完整命令链

3.1 恢复参数文件与调整路径

恢复的第一步是拿到参数文件。手册里用的是备份集里的 spfile 备份，restore spfile from '/hisbak/spfile_BSOFT_562120512_20220830_40444.ora'。这个备份文件名里带着数据库名和时间戳，生产环境做日常备份时建议保持这种命名规范——恢复的时候光看文件名就知道是哪个库、哪天哪次备份，尤其当 /hisbak 下堆着几十上百个备份集时，这个习惯能省很多查 list backup 的时间。

在恢复 spfile 之前要先startup nomount，因为此时数据库既没有控制文件也没有参数文件，只有 nomount 状态能接受 spfile 恢复。恢复完成后，create pfile from spfile生成一个可编辑的文本文件，方便我们改路径和内存参数。这一步不要跳过——直接改 spfile 里的路径参数不是不行，但没有 pfile 直观，出错了排查也费力。

3.2 控制文件恢复与备份集加载

控制文件恢复用的是备份里的控制文件备份片，命令是restore controlfile from '/hisbak/BSOFT_CONT_562120512_20220830_40443.ctl'。恢复完成后自动生成指定路径的控制文件。接下来立即执行：

RMAN> catalog start with '/hisbak/'; # 输出示例 # searching for all files in /hisbak/ # 该命令会递归扫描目录下所有备份片和归档日志并登记到控制文件

catalog start with是恢复流程里最容易漏的一步。控制文件是从备份里恢复出来的，它只认识备份时点之前记录的备份信息，而 /hisbak 里后补的备份片——比如最新的归档日志备份——它一概不知。catalog 命令的作用就是把控制文件里缺失的备份记录补进去，让 RMAN 的备份元数据和物理文件恢复一致。不执行这一步，后面的restore database和recover database会频繁报 RMAN-06139 或者找不到备份片。

之后用report schema检查数据文件清单。手册里看到的输出是 ASM 路径，文件大小全是 0，因为控制文件是从备份恢复的，还没有和实际数据文件关联。看到RMAN-06139: WARNING: control file is not current for REPORT SCHEMA是正常现象，不必慌张，它只表示控制文件不是当前状态，后续 restore 完成就好了。

3.3 RESTORE 与 RECOVER：多通道并行和时间点选择

恢复数据文件是这套流程里最耗时的一环。手册里开了 16 个通道并行恢复，这是大库恢复的标配做法。通道数量建议和主机 CPU 核数相关，太多会争 I/O，太少则跑不满磁盘带宽。16 通道对应一台中高端 2U 服务器是合理的。

RMAN> run { ALLOCATE CHANNEL C1 DEVICE TYPE DISK; ALLOCATE CHANNEL C2 DEVICE TYPE DISK; # ... 按需分配 C3 - C16 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 C1; RELEASE CHANNEL C2; # ... RELEASE CHANNEL C16 }

SET NEWNAME是这套命令的灵魂。源库文件在 ASM+DATA上，目标库是文件系统，如果不指定 NEWNAME，RMAN 会试图把文件恢复到原始的 ASM 路径上，直接报错。SET UNTIL TIME决定了恢复到哪个时间点：这里先恢复到 2022-08-30 02:00，是一个保守的起点，后面再通过追归档往前推进。

restore 完成后不要急着 recover。先做一次switch database to copy，让控制文件里的数据文件路径更新为新位置，再执行 recover。recover 同样要带SET UNTIL TIME，时间点要和 restore 保持一致或者稍晚。手册里的做法分两次推进——先恢复到 07:00，再恢复到 12:00，每追一次就open read only检查一次数据完整性，确认没问题再继续追，这个节奏我非常推荐。大库恢复最怕一口气追到最后一个归档，结果中间某个归档损坏，排查来回成本极高。

RMAN> SWITCH DATABASE TO COPY; RMAN> run { ALLOCATE CHANNEL C1 DEVICE TYPE DISK; # ... 按需分配通道 SET UNTIL TIME "TO_DATE('2022-08-30:07:00:00', 'YYYY-MM-DD:HH24:MI:SS')"; RECOVER DATABASE; RELEASE CHANNEL C1; # ... RELEASE CHANNEL C8 }

3.4 追归档的技巧：read only 检查后再推进

这套流程里最值得收藏的操作，是多次追归档的手法。每次追完归档后，用alter database open read only打开数据库检查数据状态，确认没问题再关闭、回到 mount 状态，继续追下一批归档。read only 打开不会产生任何 redo，所以不会污染恢复链。

SQL> alter database open read only; -- 检查数据文件、表空间、关键表数据后，继续追 SQL> shutdown abort; SQL> startup mount;

这里shutdown abort看着粗暴，但在恢复场景里完全合理——库本身只读，没有业务写入，abort 关闭不会丢失任何东西。如果你用shutdown immediate，反而可能因为等待某些后台任务而卡住。手册里最后一次性执行不带SET UNTIL TIME的recover database，让 RMAN 自动追到备份集里所有可用归档的最末端。

4. DBUA 升级前的检查与配置：把图形界面的活提前干完

4.1 preupgrade 脚本：升级前的体检报告

DBUA 的图形界面背后有一系列检查脚本，其中最重要的就是 preupgrade 脚本。Oracle 官方给出的标准流程里，升级前要在源库（或恢复好的克隆库）上跑一遍preupgrd.sql，它会检查数据库里是否存在会影响升级的对象——比如失效的 PL/SQL 包、过长的用户名、不支持的时区文件、审计表空间配置等。19C 对应的 preupgrade 脚本生成报告后，通常会给出一个修复脚本和一个后续执行脚本，分别对应preupgrade_fixup.sql和postupgrade_fixup.sql。

这个检查必须在 19C 的 ORACLE_HOME 下执行，而不是 11g 的 HOME。原因是 preupgrade 脚本需要读取新版本的字典信息来做比对。执行方式：

# 进入 19C 的 ORACLE_HOME cd /u01/app/oracle/product/19.14.0/db_1/rdbms/admin sqlplus "/ as sysdba" @preupgrd.sql

跑完之后会生成preupgrade_fixup.sql和postupgrade_fixup.sql，位置在$ORACLE_BASE/cfgtoollogs/<db_name>/preupgrade/。执行计划的顺序是：先跑 fixup 脚本做前期修复，再执行 DBUA，最后跑 post 脚本做收尾。如果 preupgrade 检查报出 ERROR 级别的条目，DBUA 会拒绝往下走，这是硬性门槛，不是警告。

4.2 DBUA 图形界面流程要点

DBUA 启动很简单，$ORACLE_HOME/bin/dbua即可。但有几个细节决定成败。第一，启动 DBUA 之前要先把监听配好，因为 DBUA 升级过程会尝试通过监听连接数据库实例，监听没起来的话会报连接错误，容易产生误导性的 ORA-12541 错误。第二，数据库必须处于 open 状态，DBUA 不是从 mount 或 nomount 状态做升级的。第三，19C 的 DBUA 对 JDK 版本有要求，11g 时代自带的老 JDK 不能满足 19C 的图形界面需求，一般需要在系统层面装一个较新的 JDK 版本，否则 DBUA 图形界面可能无法启动。

升级过程中，DBUA 会执行一系列内部操作：把数据字典升级到新版本、调整 compatible 参数、更新时区文件、迁移审计表等。图形界面上会显示进度，但具体内部细节基本是黑匣子，能看到的只有 stage 名称和日志。遇到卡住不要盲目点击，先去翻日志——日志位置在$ORACLE_BASE/cfgtoollogs/dbua/upgrade19x/，里面会记录每一步的耗时和错误信息，比界面上的进度条可靠得多。

4.3 DBUA 静默模式：无图形环境下的唯一选择

手册里特别提到了 DBUA 支持静默模式，参考文档是 Doc ID 2548985.1。这在远程升级、无图形环境或自动化运维场景下非常有用。静默模式的核心命令参数是-silent，配合-sid指定实例名、-oracleHome指定新 HOME 路径，以及可选的调度脚本参数。示例：

/u01/app/oracle/product/19.14.0/db_1/bin/dbua \ -silent \ -sid bsoftsb \ -oracleHome /u01/app/oracle/product/19.14.0/db_1 \ -oracleHomeForUpgrade /u02/app/oracle/product/11.2.0/db \ -executeScripts /tmp/postupgrade_fixup.sql

各参数的含义：-sid是要升级的实例名；-oracleHome是 19C 的新 HOME 路径，DBUA 最终会把实例指向这里；-oracleHomeForUpgrade是源 11g 的 HOME 路径；-executeScripts用于在升级完成后自动执行指定的 SQL 脚本，这里可以放 postupgrade_fixup.sql。静默模式执行完后，同样会生成日志，需要重点看末尾的阶段——整体升级成功但某个成分（component）升级失败的情况并非罕见，表象是日志末尾没有 ERROR，实际查dba_registry_updated时却能看到有的组件版本没升上来。

5. 升级避坑记录：三次翻车的现象、原因与对策

5.1 追归档报 RMAN-06054：备份里没有你要的那个 sequence

现象：执行不带SET UNTIL TIME的recover database时，RMAN 报错RMAN-03002和RMAN-06054，提示media recovery requesting unknown archived log for thread 1 with sequence 25197 and starting SCN of 18157927920。意思是要继续做介质恢复，但 RMAN 找不到 sequence 25197 这个归档日志。

原因：报错变量sequence 25197说明数据库需要这个序号的归档才能继续往前恢复，但备份集里实际没有覆盖到它。我在手册里的案例中遇到的就是这种情况——/hisbak里归档备份片的最新 sequence 只到 25192（thread 1），而数据库要追到 25197，差出来的那几段归档没有备份进来，恢复链在这里断掉。

解决：先冷静确认可用归档范围，用list backup of archivelog from time 'sysdate-1';查看最近的归档备份集里实际包含了哪些 sequence。如果确认差几个，且生产端还能找到对应的在线归档，就把缺的拷到 /hisbak 再 catalog 登记一遍。如果生产端已经清掉了，那么恢复点就到此为止——改用SET UNTIL TIME恢复到最后一个完整归档对应的时间点。从那以后我每次追归档前，都会先list backup of archivelog确认范围，而不是盲目recover database。

5.2 read only 打开后想继续恢复，直接报错

现象：alter database open read only检查完数据后，没有关闭数据库，直接执行recover database，RMAN 报错无法继续，数据库状态不符合介质恢复的要求。

原因：介质恢复要求数据库处于 mount 状态。read only 打开后数据库已经处于 open 状态，此时是不能做 recover 的。这个顺序问题在恢复流程里很常见——read only 打开的目的就是先检查数据完整性，检查完要继续追归档，必须先把状态退回 mount。

解决：执行shutdown abort，然后startup mount，再执行 recover。注意这里用 abort 不是误操作——正在做恢复的库没有任何业务事务，abort 不会产生并发问题。这个坑几乎每次追归档都会遇到，熟练之后反而变成了习惯动作：open read only → 检查 → abort → mount → recover。

5.3 DBUA 升级过程中卡在某个 stage 不动

现象：DBUA 图形界面或静默模式的日志显示长时间停留在某个阶段，比如upgrade catalog或recompile阶段，进度条不再前进，CPU 和 I/O 没有明显波动。

原因：DBUA 执行的内部步骤对系统资源有硬性需求。最常见的原因是临时表空间空间不足，或者归档日志目录满了导致内部操作无法继续。另一个隐蔽原因是数据库中存在大量失效对象，尤其是巨大的 PL/SQL 包体，utlrp.sql重编译阶段会特别缓慢——这时候不是卡死，是在做大量无输出状态的工作。

解决：先看日志确认到底卡在哪一步，同时检查临时表空间使用情况和告警日志alert_<sid>.log。临时表空间不足就扩容，磁盘满就清理归档。如果确认是重编译引起的慢，给足耐心，观察v$session_longops里有没有重编译相关的会话在跑。注意 DBUA 升级过程中的失败重跑成本很高，一旦走到一半失败，往往需要恢复到升级前的备份重来一次，所以升级前扩容临时表空间、预留足够磁盘空间、确认归档目录空闲，这三件事必须提前做到位。

6. 升级后的验证清单与回退策略：别急着切业务

6.1 组件版本与状态检查

升级完成不等于万事大吉。DBUA 跑完后，第一件事是用 SQL 确认所有组件都处于VALID状态，版本是 19C 对应的版本号：

set linesize 200 col comp_id format a20 col version format a15 col status format a15 select comp_id, version, status from dba_registry order by comp_id; -- 检查升级过程中更新过的组件 select comp_id, version, status from dba_registry_updated order by comp_id;

如果发现有组件状态是INVALID或者是UPGRADED但版本不对，需要单独处理。最常见的处理手段是重跑utlrp.sql重编译失效对象。升级完成后首次以 19C 身份打开数据库，会有一段相对较慢的启动过程，因为系统在做字典升级后的内部初始化，这不代表异常。另一个要确认的是监听配置——19C 和 11g 的 listener.ora 格式有差异，要确认静态注册和动态注册的配置项都适配新版本，否则应用连接串可能失效。

6.2 回退方案：最安全的岸还在

这套方案最核心的保障是：生产库从始至终没有被改动。升级过程中的每一次变更都发生在克隆环境上，如果 DBUA 升级失败、数据字典损坏、应用兼容性测试不过，回退路径非常清晰——切回生产库，业务继续跑 11g，什么都不影响。正因为有这个兜底，整个升级过程可以减少很多心理负担，遇到问题可以从容排查而不是慌乱操作。

6.3 验证顺序与收尾习惯

升级完成后的验证顺序是我个人比较推荐的做法：先看组件状态，再打开数据库让应用做基础功能测试，然后观察一两个小时后端日志和 AWR 报告，确认没有诡异的 FG 或后台等待事件。整个验证跑通后，才对生产环境做规划停机和最终切换。手册里涉及到的补丁检查、时间点恢复、README 里提到的日志告警检查，这些内容值得在升级项目开工前单独整理一份清单。

从那次升级之后，我每次做数据库大版本升级都强制走一遍固定流程：备份恢复、read only 验证、追归档确认断点、preupgrade 检查、记录 DBUA 每个 stage 的时间点、升级后逐个组件确认VALID、最后留足观察期再切业务。这套动作虽然朴实，但确实帮我避开了后续几次升级项目里更多的坑。希望帮到你。

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