Oracle 11.2.0.4升级19C：RMAN迁移、DBUA升级与验收避坑

简介：《Oracle 11g 到 19C 数据库升级详尽指导手册》面向具备一定运维基础的数据库管理员和系统运维人员，围绕使用 DBUA 工具将 Oracle 11g 单机库升级至 19C 的完整流程展开，重点解决升级前备份恢复、版本升级路线判断、必要配置调整及异常处理等实际问题，适合在维护窗口内对照执行。资源包内含 1 个 PDF 文件，大小约 3.18MB，以步骤说明、命令示例和注意事项为主，查阅方便。目前已有 1360 人学习下载。手册覆盖前期备份与 RMAN 恢复、DBUA 图形化及静默升级、MOS 参考文档与直接/间接升级路线，并提示主机版本要求、日志与警告检查方法，附有常见故障解决方案，可帮助读者按顺序执行、快速定位问题并保留失败回退路径，兼顾操作规范与风险控制。

1. 升级路线的判断：11.2.0.4 直连 19C，版本对了主机不一定对

上周又碰到一个典型的场景：一台老业务库还停在 11.2.0.4，补丁停在 2020 年 10 月的 31537677，厂商已经不再出补丁，要求走 Oracle 19C 的数据库升级。第一反应都是“把 DBUA 拉起来点下一步”，结果一查主机是 Linux 6，第一个问题根本不在 DBUA，而在机器上。19C 对操作系统的最低要求是 Linux 7，源库主机还停在 6 的，升级动作要往后放，先找一台 RHEL 7 的新机器把 19C 软件装好，用 RMAN 把生产库搬过去，再在新机器上用 DBUA 升。这条路径多花半天装机时间，但生产库原封不动躺着，升级失败随时能回退，比在唯一一台机器上冒险划算得多。下面按我实际走过一遍的顺序，从主机准备、软件安装、备份恢复，一直写到 DBUA 跑完怎么验收。

2. 目标机装 19C 软件：两个 ORACLE_HOME 并存的安装顺序

19C 的软件安装和 11g 有个本质差别：新机器上要同时存在两个 ORACLE_HOME，一个 11.2.0.4 用来承载恢复出来的源库，一个 19.14 用来做升级目标。这两个 HOME 不能装在同一个父目录下互相踩，也不能让环境变量在中间切换时指错。我一般把 11g 放/u02/app/oracle/product/11.2.0/db，19c 放/u01/app/oracle/product/19.14.0/db_1，数据文件统一/oradata，归档单独/arch，四个目录分开挂载，恢复阶段写满哪块盘都一眼看得出来。

2.1 主机最低要求与目录规划

RHEL 7.9 是这套组合里最省事的版本，7.6 到 7.9 都行，别上 8，19.14 那个时间点的认证列表还没覆盖到。装系统时选 Server with GUI，DBUA 图形界面要用到 X11 库，最小化安装后面补包会补到怀疑人生。

依赖包一次性装齐，缺一个到 runInstaller 检查时才知道，来回折腾：

# RHEL7 上 19c 的常规依赖，compat-libstdc++-33 和 libaio-devel 最容易漏 yum install -y binutils compat-libcap1 compat-libstdc++-33 gcc gcc-c++ glibc \ glibc-devel ksh libaio libaio-devel libgcc libstdc++ libstdc++-devel \ libX11 libXau libXi libXtst libxcb make net-tools nfs-utils sysstat unzip

内核参数按 19c 的推荐值写进/etc/sysctl.d/99-oracle.conf，重点是kernel.shmmax要大于等于 SGA 大小，fs.aio-max-nr不够会导致 ASM 和异步 IO 报错：

fs.aio-max-nr = 1048576 fs.file-max = 6815744 kernel.sem = 250 32000 100 128 kernel.shmall = 1073741824 kernel.shmmax = 4398046511104 kernel.shmmni = 4096 net.core.rmem_default = 262144 net.core.rmem_max = 4194304 net.core.wmem_default = 262144 net.core.wmem_max = 1048576 net.ipv4.ip_local_port_range = 9000 65500

/etc/security/limits.conf里给 oracle 用户放开 nofile 和 nproc，这一条不设，库能起来，但并发一上来就报 ORA-00059 或者直接连不上：

oracle soft nproc 16384 oracle hard nproc 16384 oracle soft nofile 1024 oracle hard nofile 65536 oracle soft stack 1024 oracle hard stack 32767 oracle soft memlock unlimited oracle hard memlock unlimited

还有一处经常被忘掉：/dev/shm。源库参数里如果配了memory_target（AMM 方式），19c 在 Linux 上还是靠 tmpfs 撑起来的，默认/dev/shm只有物理内存的一半，一旦memory_target超过它，起库直接 ORA-00845。上机第一件事df -h /dev/shm看一眼，不够就在/etc/fstab里把 tmpfs 调到大于memory_target，或者干脆在升级窗口里把 AMM 拆成sga_target+pga_aggregate_target的 ASMM，19c 上这是更主流的配法。

2.2 19C 软件静默安装与 oratab 双记录

图形安装在这里没意义，静默装更快也更可复现。响应文件我只改必要的几项，其余用默认：

# /soft/db_install_19c.rsp 关键片段 oracle.install.option=INSTALL_DB_SWONLY # 只装软件，不建库，库是从 11g 恢复过来的 UNIX_GROUP_NAME=oinstall INVENTORY_LOCATION=/u01/app/oraInventory ORACLE_HOME=/u01/app/oracle/product/19.14.0/db_1 ORACLE_BASE=/u01/app/oracle oracle.install.db.InstallEdition=EE oracle.install.db.DBA_GROUP=dba oracle.install.db.OPER_GROUP=oinstall

# 用 19.14 的 gold image 直接装，省掉后面再打 RU 的步骤 cd /soft/LINUX.X64_193000_db_home ./runInstaller -silent -ignorePrereqWarning \ -responseFile /soft/db_install_19c.rsp \ -oraInventoryLocation /u01/app/oraInventory

-ignorePrereqWarning只在主机检查项是“警告”级别时用，比如 swap 偏小、/tmp不到 1G；如果是“失败”级别的检查项，硬扛过去装完也是废的，别偷这个懒。装完按提示跑两个脚本，顺序不能反：先oraInventory/orainstRoot.sh，再$ORACLE_HOME/root.sh。

软件装完，/etc/oratab里会有两条记录，一条 11g 一条 19c，这是正常的，也是必须的——DBUA 靠 oratab 和监听来识别源库。问题是两条记录的 SID 如果写成一样，后面切环境变量时会非常难受。我习惯让恢复出来的库用独立的ORACLE_SID，比如生产叫bsoft，升级机上恢复成bsoftsb，db_name保持bsoft不变，db_unique_name改成bsoftsb，两边互不干扰。

提示：安装完成后别急着建监听。19c 的监听要用 19c 的lsnrctl起，端口先用 1522 错开生产环境的 1521，等升级验收完成再决定是否切回标准端口。

2.3 preupgrade.jar 跑一遍升级前体检

DBUA 自己会做预检查，但它是黑盒，出问题只给你一句“Prechecks failed”。真正好用的是 19c HOME 里自带的preupgrade.jar，它在源库上跑，输出一份带修复脚本的报告，升级窗口前一周我就跑一遍，把能提前处理的问题处理掉。

# 注意：java 和 jar 都来自 19c 的 HOME，连接的却是 11g 的源库 export ORACLE_HOME=/u01/app/oracle/product/19.14.0/db_1 export ORACLE_SID=bsoftsb export PATH=$ORACLE_HOME/bin:$PATH $ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/rdbms/admin/preupgrade.jar \ FILE TEXT DIR /home/oracle/preup

跑完在/home/oracle/preup下会有三个东西：preupgrade.log是问题清单，preupgrade_fixups.sql是升级前要执行的修复脚本，postupgrade_fixups.sql是升级后执行的收尾脚本。日志里我最常盯三类：已安装组件里有没有 19c 已经不支持的（Streams、Multimedia 这类，装了要么先删要么找替代方案）、无效对象和无效组件、字符集是不是 AL32UTF8。字符集这一项尤其要紧，11g 时代大量库是ZHS16GBK甚至US7ASCII，DBUA 到那一步会给你一个警告然后继续，但有些业务数据在 19c 下读出来就是乱码，这种事千万别留到升级窗口里才发现。

preupgrade_fixups.sql建议在源库上直接跑，它做的事情包括清理回收站、检查SYSTEM和SYSAUX空间、把一些必须提前处理的组件状态归位。跑完之后再跑一次preupgrade.jar，确认告警清干净，这一步做完，DBUA 的前置检查基本不会翻车。

3. 用 RMAN 把生产库搬到升级机：spfile、控制文件、restore 三段式

搬迁的核心思路很简单：生产库不动，用 RMAN 全备 + 归档在升级机上把库恢复出来，追到尽量接近生产的时间点，然后停在这个状态交给 DBUA。恢复过程中只做只读打开验证，不做写入，这样归档还能继续往前追，时间点可以一点点逼近。整个过程分三段：先参数文件，再控制文件，最后数据文件。

3.1 还原 spfile 并改写成 pfile：db_name 与 db_unique_name 别写反

第一段是把源库的 spfile 从备份片里捞出来。此时实例还没起，RMAN 用startup nomount会用一个默认参数起一个空壳实例，然后restore spfile把真正的参数文件落盘：

[oracle@oracle19c ~]$ source ~/.bash_profile # 确认 ORACLE_HOME 指向 11g 的 HOME，不是 19c [oracle@oracle19c ~]$ rman target / RMAN> startup nomount; RMAN> restore spfile from '/hisbak/spfile_bsoft_20220830_40444.ora'; RMAN> exit

这里有个血泪教训：升级机上存在两个 ORACLE_HOME，source .bash_profile之后一定要echo $ORACLE_HOME确认一遍。我见过把两边 HOME 记反的环境表，结果restore spfile恢复出来的参数文件被写进了 19c 的dbs目录，后面 DBUA 一上来就把 11g 的库认成了 19c 的，报错信息完全不知所云。

spfile 是二进制的，路径全是源库的，必须转成 pfile 改完再转回去：

SQL> create pfile='/home/oracle/pfile.ora' from spfile;

改的时候真正需要动的只有几项，其余保持原样：

audit_file_dest、control_files、db_create_file_dest这几个目录必须先mkdir -p建好并改属主，参数指向一个不存在的目录，起库时的报错是 ORA-09925，跟权限问题混在一起很难一眼看出。

改完把 pfile 转成 11g HOME 下的 spfile：

SQL> startup nomount pfile='/home/oracle/pfile.ora'; SQL> create spfile='/u02/app/oracle/product/11.2.0/db/dbs/spfilebsoftsb.ora' from pfile='/home/oracle/pfile.ora';

create spfile的目标路径必须落在 11g 的 HOME 下，因为将来起这个库的是 11g 的实例，19c 的 HOME 只负责升级。

注意：源库带过来的一些 11g 遗留参数，比如sec_case_sensitive_logon，在 19c 上已经失效或被标记为废弃，pfile 里留着不影响起库，但别指望它生效；升级完成后建议清理一遍，别当成有效配置继续用。

3.2 还原控制文件与 catalog 备份片

第二段是控制文件。控制文件里记录了备份片的位置、数据文件清单、归档序列，把它先还原回来，RMAN 才知道后面该去哪找东西：

[oracle@oracle19c:/hisbak]$ rman target / RMAN> restore controlfile from '/hisbak/bsoft_CONT_20220830_40443.ctl'; RMAN> sql 'alter database mount'; RMAN> catalog start with '/hisbak/';

alter database mount是必须的，控制文件还原完实例还停在 nomount，不 mount 起来没法做后续的 restore。

catalog start with是把目录下所有备份片重新登记进控制文件。这一步会扫很久，几十上百个备份片是常态，别以为卡死了。登记完report schema能看到完整的数据文件清单，但会带一个RMAN-06139: WARNING: control file is not current for REPORT SCHEMA，这是正常的——控制文件来自备份，里面记录的当前状态本来就是旧的，不影响恢复。

清单里如果数据文件名带+DATA前缀，说明源库是 ASM 存储，升级机是文件系统，路径对不上，这正是下一节SET NEWNAME要解决的事。

3.3 restore database 的 SET NEWNAME、UNTIL TIME 和 SWITCH

第三段是真正的数据文件还原。这里的两个关键点：一是SET NEWNAME把 ASM 路径改写到本地，二是UNTIL TIME把恢复目标定在某个时间点，先把库拉到一个可用状态，后面再靠归档往前追。

run { 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 '/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 C3; RELEASE CHANNEL C4; }

通道数不是越多越好。源库备份时开了 16 个通道，备份片被切得很碎，恢复时通道数一般取min(备份片数量, CPU 核数)，4 到 8 个是常见区间，再往上磁盘 IO 先饱和，加通道只会互相抢带宽。%b这个占位符也别换成%f，%f是绝对文件号，恢复出来的文件名会变成一串数字，后面排查哪个文件对应哪个表空间要花很久。

RESTORE只负责把数据文件从备份片里拷出来，拷完数据库还是不一致状态，必须接RECOVER。这两步分开写是有意为之——中间可以插一次SWITCH DATABASE TO COPY，把控制文件里的数据文件指向新位置，不然后面的 recover 会去找原来+DATA下的路径，直接报找不到文件。

还原完成后立刻看一眼/oradata的剩余空间。临时表空间文件也在还原范围内，源库如果有一个 30G 的临时文件，还原时一样要占 30G，空间估算按dba_data_files加dba_temp_files的总和乘 1.2 来留余量比较稳。

4. 追归档与 DBUA 升级：从 read only 验证到正式升级

4.1 recover 分批推进与 RMAN-06054 的处理

RESTORE完成时，数据文件只到备份那一刻的状态，后面几个小时的归档还在源库上。这时候把源库的归档备份片拷到/hisbak，catalog进来，然后RECOVER往前推：

run { ALLOCATE CHANNEL C1 DEVICE TYPE DISK; ALLOCATE CHANNEL C2 DEVICE TYPE DISK; SET UNTIL TIME "TO_DATE('2022-08-30:12:00:00','YYYY-MM-DD:HH24:MI:SS')"; RECOVER DATABASE; RELEASE CHANNEL C1; RELEASE CHANNEL C2; }

分批追的好处是每追一段可以alter database open read only验证一次，确认库能起来、没有坏块、业务表能查，再决定要不要继续。如果一次性追到底，中间哪一步缺了归档，前面几小时全白做。

RECOVER报RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 25197是最常见的错误，意思是 RMAN 要 seq 25197 的归档，但本地没有。这不是数据损坏，纯粹是归档不全。处理办法是先看清楚要的是哪个序列：

RMAN> list backup of archivelog from time 'sysdate-1';

输出里能看到每个备份片包含的线程号、序列号区间、起止 SCN。对照报错里的 25197，去源库找覆盖这个序列的归档备份，拷过来重新catalog start with再recover就行。如果源库的归档已经被删了，那就只能停在上一个能追到的 SCN，用open resetlogs收尾，这时候要评估丢掉的那段时间的数据能不能接受。

4.2 read only 打开验证与 resetlogs 收尾

只读打开是这套流程里最有价值的一个动作。它能在不影响恢复进度的前提下，把库真正打开一次，验证数据文件、控制文件、redo 三者是不是一致：

SQL> alter database open read only;

打开后跑几条业务 SQL、查几个核心表、select count(*)对一下数量级，比任何日志都直观。验证完如果要继续追归档，顺序不能错：

SQL> shutdown abort; SQL> startup mount;

必须先回到 mount 状态才能继续recover，在 read only 状态下直接 recover 会报 ORA-01096。这里用shutdown abort而不是immediate，是因为只读实例上可能有残留的查询进程，abort 更干脆，恢复出来的库不涉及数据一致性风险。

追到最后一个可用归档之后，最后一步是正常打开。如果在线重做日志没有从源库一起拷过来，alter database open会报 ORA-01589，必须带 resetlogs：

SQL> alter database open resetlogs;

resetlogs一执行，之前的备份链和对源库的追溯关系就断了。所以我的习惯是打开之后立刻做一次全备，作为升级前的基线备份，这样即使 DBUA 中途失败，也有一条完整可回退的路径，不至于只能从头再来一遍恢复。

注意：open resetlogs之后，源库的归档就再也追不进来了。决定执行这条命令之前，确认业务方已经接受这个时间点。

4.3 DBUA 图形界面与静默两种跑法

正式升级前有几件事必须就位，缺一件 DBUA 就卡在预检查：

• 数据库以读写方式打开，不是 read only，也不是 mount；
• 归档模式开着，log_archive_dest_1有可用空间；
• 监听已经起来，且是 19c HOME 下的监听，lsnrctl status能看到这个实例；
• 环境变量指向 19c 的 HOME，ORACLE_SID指向待升级的库；
• /etc/oratab里两条记录都对。

图形方式适合第一次做，能看到每一步的预检查结果。$ORACLE_HOME/bin/dbua起来之后，选源库 SID，选“Upgrade”，一路下一步，中间会让你指定新的SYSAUX、TEMP、UNDO表空间的位置和大小，还会问要不要开 Guarantee Restore——这个一定要开，它会在升级前自动做一次备份，失败时能一键回退，代价只是多花十几分钟。

批量或者远程没有图形环境时，用静默模式：

export ORACLE_HOME=/u01/app/oracle/product/19.14.0/db_1 export PATH=$ORACLE_HOME/bin:$PATH export ORACLE_SID=bsoftsb $ORACLE_HOME/bin/dbua -silent -sid bsoftsb \ -oracleHome $ORACLE_HOME \ -sysDBAUserName sys -sysDBAPassword '你的口令' \ -diagnosticDest /u01/app/oracle \ -recoveryAreaDestination /arch \ -restore

-oracleHome是目标 HOME，不是源 HOME，写错会直接报找不到可升级的实例。-restore对应图形界面的 Guarantee Restore。-diagnosticDest决定 ADR 目录落哪，升级后如果出问题，trace 全在那儿。

整个升级过程二十来分钟到一个多小时，取决于数据字典大小和无效对象数量。日志在$ORACLE_BASE/cfgtoollogs/dbua/<SID>/下按时间戳分目录，dbua.log是主流程，同目录下还有各阶段的检查报告。升级失败时先看dbua.log最后 200 行，里面的 ORA 错误基本能定位到具体阶段。

4.4 升级后的四件事：utlrp、compatible、时区、统计信息

DBUA 跑完不代表结束，有四件事不做，后面的问题会以各种奇怪的方式冒出来。

第一件，编译无效对象。DBUA 会自动跑一次utlrp.sql，但数据字典大的库经常一次编译不干净：

SQL> @?/rdbms/admin/utlrp.sql -- 重复执行直到无效对象数量不再下降 SQL> select count(*) from dba_objects where status='INVALID';

第二件，提升compatible参数。19c 的默认值还是 11.2.0.4，不提升的话很多新特性用不上，优化器行为也停在老版本：

SQL> alter system set compatible='19.0.0' scope=spfile;

这一步执行完再想降回 11g 就没门了，只能靠备份恢复，所以放在所有验证通过之后。

第三件，时区文件。11g 的时区版本和 19c 差了好几版，带 TIMESTAMP WITH TIME ZONE 字段的表在跨时区计算时会出错：

SQL> select * from v$timezone_file; SQL> @?/rdbms/admin/utltz_upg_check.sql -- 先看检查结果 SQL> @?/rdbms/admin/utltz_upg_apply.sql -- 再执行升级，会自动建备份表

第四件，重新收集数据字典统计信息，让优化器基于 19c 的规则重建执行计划：

SQL> execute dbms_stats.gather_dictionary_stats;

这四条做完，再补一次全备，升级这个动作才算真正收口。

5. 升级避坑记录：五个把我卡住的现场

5.1 起不来：跟实例、内存、监听有关的三个现场

第一坑，DBUA 预检查报“找不到要升级的实例”。

现象是图形界面里 SID 下拉框是空的，或者静默模式直接退出，日志里只有一句No database found。原因是监听还是 11g 的 HOME 起的，lsnrctl status里那个实例注册的是 11g 的服务，DBUA 用 19c 的 HOME 去连就连不上。解决办法是先停掉旧监听，用 19c HOME 下的lsnrctl起一个 1522 端口的新监听，并在listener.ora里把SID_LIST_LISTENER加上这个 SID 的静态注册，lsnrctl status能看到Service "bsoftsb" has 1 instance(s)再跑 DBUA。

第二坑，恢复出来的实例起不来，报 ORA-00845: MEMORY_TARGET not supported on this system。

现象是startup nomount直接失败，参数文件看着没问题。原因是 pfile 里带过来的memory_target是 120G，而新机器的/dev/shm默认只有物理内存的一半，64G 挂在那儿，够不着。解决办法有两个：临时mount -o remount,size=130G /dev/shm，或者把 AMM 换成 ASMM，删掉memory_target保留sga_target和pga_aggregate_target。我倾向后者，19c 上 AMM 已经是边缘配置，换掉一劳永逸。

第三坑，控制文件还原成功，alter database mount报 ORA-00205。

现象是控制文件明明 restore 成功了，挂载却报错。原因是控制文件里记录的control_files参数值是源库的 ASM 路径，而实例实际读的是 pfile 里改过的本地路径，两边对不上。解决办法是确认 pfile 里control_files只写了一行、路径确实存在且属主是 oracle，然后重建 spfile 再起。改参数的时候手抖写成两行路径，也会触发同样的报错。

5.2 升不上去：跟归档、字符集、空间有关的两个现场

第四坑，DBUA 跑到一半失败，回滚后数据库起不来，报 ORA-01555 或者数据字典不一致。

现象是升级进度到 70% 左右中断，日志里是快照过旧。原因是 UNDO 表空间在升级前没扩容，升级过程本身要改大量数据字典，UNDO 撑不住。解决办法是升级前把 UNDO 表空间扩到至少 2G，undo_retention临时调到 10800，同时确认undo_tablespace指向的是自动管理的 UNDO。升级完成后undo_retention再改回去。

第五坑，DBUA 预检查报字符集警告，忽略了继续升级，升完发现某些中文数据是乱码。

现象是查询结果里中文变成问号或者方块。原因是源库是US7ASCII或者ZHS16GBK，升级到 19c 之后应用端按 UTF8 解析。字符集不是升级工具能帮你改的，它属于数据迁移范畴，必须在升级窗口之外单独做。处理办法是升级前用select * from nls_database_parameters where parameter='NLS_CHARACTERSET'确认，不是AL32UTF8的提前规划字符集转换，把这项排除在升级窗口之外。

第六坑，DBUA 卡在最后一步很久，日志里刷ORA-19809: limit exceeded for recovery files。

现象是升级进行到一半不再前进，磁盘没满但归档写不进去。原因是db_recovery_file_dest_size还是源库的 200G，而升级机上的/arch实际只有 150G，19c 预检查不会查这个。解决办法是升级前把db_recovery_file_dest_size调成小于实际挂载容量的值，留 20% 余量，同时crosscheck archivelog all清理掉已经备份过的归档。

6. 装完怎么验证跑通：一份可以照着敲的验收清单

DBUA 报“升级成功”那一刻，我从来不直接交给业务方。19c 的验收要落到具体查询上，光看日志不算数。下面这几条是我每次必跑的，按顺序来，一条不过就停下来查。

-- 组件状态：除 CATALOG / CATPROC 之外都应该是 VALID select comp_id, version, status from dba_registry order by comp_id; -- 打过哪些 RU，确认和预期版本一致 select patch_id, action, status, action_time from dba_registry_sqlpatch order by action_time desc; -- 无效对象，反复跑 utlrp.sql 后应该归零 select owner, object_type, count(*) from dba_objects where status='INVALID' group by owner, object_type order by 3 desc; -- 时区版本 select * from v$timezone_file; -- 关键参数对照 select name, value from v$parameter where name in ('compatible','optimizer_features_enable','db_name','db_unique_name','nls_characterset');

光有查询不够，还要有对照。升级前我在源库记下三组数字，升级后逐个比对：

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