简介：这份《Oracle 11g 到 19C 数据库升级详尽指导手册》面向具备一定运维能力的数据库管理员（DBA），聚焦于借助 DBUA（Database Upgrade Assistant）工具将 Oracle 11g 安全迁移至 19C 的完整维护场景。内容涵盖前期备份与恢复、升级路线选择、必要配置调整及注意事项，并强调检查脚本生成的日志与警告，帮助读者应对升级中可能出现的异常情形。资源包共 1 个 PDF 文件，大小约 3.18MB，以图文与命令示例结合的方式呈现，便于按步骤对照操作。手册中梳理了直接升级与间接升级路径、主机版本要求、RMAN 备份恢复与参数文件调整等关键环节，并附有多个故障解决方案，可帮助 DBA 在提升性能与安全性的同时，降低升级风险、快速定位问题。目前已有 1350 人学习，适合需要系统掌握 DBUA 升级流程、查漏补缺的运维人员参考。
1. 从 11g 到 19C：为什么我劝你先别急着点 DBUA 的“下一步”
手里还跑着 11.2.0.4 的库，补丁停更、官方支持到期，业务侧又催着要新特性，升级这件事基本躲不掉。真到动手那天，多数人第一反应是打开 DBUA 图形界面一路点下去——这正是我想先泼盆冷水的地方。DBUA 本身没问题，它是官方给的图形化升级向导，能自动跑预检查、调参数、编译无效对象，省掉大量手工活。但它有个前提：源库必须已经以“干净、可升级”的状态躺在目标主机上。如果你跳过 RMAN 恢复、跳过预检查脚本、跳过源库自检，直接在生产库上点升级，翻车概率极高，而且回退成本大到让你怀疑人生。
这份手册的价值就在这：它把“11g 单机通过 DBUA 升级到 19C”拆成了一条可复现的链路——先在生产库做全备，用 RMAN 把备份恢复到一台独立的 19C 目标主机上，在副本上完成升级验证，生产库原封不动留着当后悔药。适合有一定 RMAN 基础、手头有 11.2.0.4 单机库、准备往 19C 迁的 DBA。下面按我实际拆这套流程的顺序讲，重点放在恢复、预检查和 DBUA 静默执行这三段最容易出问题的地方。
2. 升级路线与主机前置条件：先确认你的库“够不够格”直连 19C
DBUA 不是万能跳板，Oracle 对升级路径卡得很死。手册里那张升级路线表是整件事的地基，先对着它确认你的源库版本落在哪一档，再决定是一步到位还是得中转。
2.1 直连与中转：你的 11g 到底能不能直接升 19C
按官方路线，能直接升级到 19.x 的源库版本是：11.2.0.4 及以上、12.1.0.2、12.2.0.1、18.1。注意这里写的是 11.2.0.4and Higher，也就是说 11.2.0.4 是直连 19C 的最低门槛。低于这个版本就得走中转：
| 源库版本 | 中转路径 | 目标 |
|---|---|---|
| 11.2.0.1 / 11.2.0.2 / 11.2.0.3 | 先升到 11.2.0.4 | 19.x |
| 11.1.0.6 / 11.1.0.7 | 先升到 11.2.0.4 | 19.x |
| 10.2.0.2 ~ 10.2.0.5 | 先升到 11.2.0.4 或 12.1.0.2 | 19.x |
| 10.1.0.5 | 先升到 11.2.0.4 或 12.1.0.2 | 19.x |
| 9.2.0.8 及更早 | 先升到 11.2.0.4 | 19.x |
| 12.1.0.1 | 先升到 12.1.0.2 或 12.2.0.1 | 19.x |
我一般会先跑一句select version from v$instance;和select * from v$version;把源库版本钉死，再对照这张表。别凭记忆，生产库上版本号记错一位，整条路线就白规划了。
2.2 操作系统这道硬门槛：Linux 6 上装不了 19C
手册里有一句很容易被忽略但极其致命的话：19C 对操作系统支持的最低要求是 Linux 7。如果你的 11g 源库跑在 Linux 6 上，那台机器根本装不了 19C 的 Oracle Home，DBUA 连启动的机会都没有。这种情况下唯一的路是准备一台 Linux 7 的新主机，装好 19C 软件，再把源库通过 RMAN 恢复过去。
所以动手前先确认两件事：目标主机的 OS 版本是否 ≥ Linux 7；目标主机上 19C 的 ORACLE_HOME 是否已经装好、补丁是否到位。手册环境里目标库用的是 19.14.0.0.220118，源库是 11.2.0.4.201020，两边都带了具体补丁号——这个习惯值得学，升级前把源库和目标库的补丁号都记下来，后面排查兼容性问题时能省很多事。
2.3 为什么坚持“恢复到副本再升级”
手册里明确写了：源库是生产环境，目标库是升级环境，通过 RMAN 把生产库备份恢复到目标库，保留生产环境用于失败回退。这是整套方案里我最认可的一点。DBUA 升级过程中会修改数据字典、编译对象、动参数文件，一旦中途失败，源库如果被直接改过，回退就是一场灾难。用副本升级，最坏情况就是副本废掉，生产库照常跑，重来一遍即可。
代价是你要多准备一台主机、多一份存储、多花一次恢复的时间。但和“升级失败导致生产库不可用”比起来，这点成本不值一提。我见过太多图省事直接在生产库上点 DBUA 的，最后卡在某个无效对象上进退两难。
3. RMAN 恢复副本库：把生产库“克隆”到 19C 主机上
这一段是整篇手册里命令最密、最容易出错的部分。目标是把生产库的备份在 19C 主机上还原成一个能 mount、能追归档的副本，为 DBUA 提供源库。整个过程分恢复参数文件、控制文件、加载备份、restore、recover 五步，顺序不能乱。
3.1 恢复参数文件并重建 spfile
先从备份里把 spfile 捞出来，再基于它生成 pfile 做路径调整。手册里的做法是先startup nomount，然后restore spfile：
# 加载 oracle 环境变量，RMAN 才能找到目标库 source .bash_profile # 进入 RMAN，目标库此时还没起来 rman target / # 启动到 nomount，只为恢复 spfile RMAN> startup nomount; # 从备份片里恢复 spfile RMAN> restore spfile from '/hisbak/spfile_BSOFT_562120512_20220830_40444.ora';恢复出 spfile 后，手册用create pfile from spfile导出一份文本参数文件，然后手工改路径。这一步的逻辑是：生产库的参数里写的是生产环境的目录（比如+DATA、原 audit 路径），副本库的目录结构不一样，必须逐项改掉，否则启动时找不到文件。手册里改动的关键项包括audit_file_dest、control_files、db_recovery_file_dest、db_unique_name、diagnostic_dest等，还顺手把sec_case_sensitive_logon设成了 FALSE——这是 11g 迁移到 19C 时密码大小写敏感的常见处理，19C 默认开启大小写敏感，老应用连不上时经常栽在这。
# 建好参数文件里引用的目录，否则启动报错 mkdir -p /u02/app/oracle/admin/bsoftsb/adump mkdir -p /oradata/bsoftsb/controlfile/ # 编辑 pfile，把路径、db_unique_name 等改成副本库的 vim /home/oracle/pfile.ora # 用 pfile 启动到 nomount，再据此生成副本库自己的 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';参数说明：db_unique_name必须和生产库区分开，否则 Data Guard 或归档相关配置会冲突；control_files指向的目录要提前建好；db_recovery_file_dest_size手册给了 200G，副本库追归档时空间不够会直接卡住恢复，这个值按你实际归档量估。
3.2 恢复控制文件并 catalog 备份
参数文件就位后，恢复控制文件，mount 数据库，再把备份目录注册进 RMAN 的 catalog：
rman target / # 从备份片恢复控制文件 RMAN> restore controlfile from '/hisbak/BSOFT_CONT_562120512_20220830_40443.ctl'; # 挂载数据库，此时数据文件还没恢复 RMAN> sql 'alter database mount'; # 把 /hisbak/ 下所有备份片注册进控制文件 RMAN> catalog start with '/hisbak/';catalog start with这步很关键。控制文件是从备份恢复的，它并不知道/hisbak/目录下还有哪些备份片可用，必须手动扫一遍注册进去，后面restore database才能找到数据文件备份。手册里 catalog 之后跑了REPORT SCHEMA，输出里能看到一堆数据文件还指向+DATA的 ASM 路径——这说明控制文件里记的还是生产库的原始路径，所以下一步 restore 必须用SET NEWNAME重定向。
3.3 restore 与 recover：用 SET NEWNAME 重定向，用 UNTIL TIME 控时间点
手册把 restore 和 recover 分成两个独立的时间点：restore 到2022-08-30:02:00:00，recover 到2022-08-30:07:00:00，之后还能继续往前追到12:00:00。这个设计很实用——先恢复到某个较早的时间点，后续靠归档一点点往前推，只要不 open read write，随时可以停。
run { # 开 16 个通道并行恢复，加快速度 ALLOCATE CHANNEL C1 DEVICE TYPE DISK; -- ... C2 到 C16 省略，实际按 CPU 和 IO 能力配 ALLOCATE CHANNEL C16 DEVICE TYPE DISK; # 关键：把数据文件从 ASM 路径重定向到本地文件系统 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 C16; }SET NEWNAME FOR DATABASE TO '/oradata/BSOFTSB/datafile/%b'里的%b是 RMAN 的占位符，代表数据文件的原始文件名。这样所有数据文件都会被还原到本地目录，而不是原来的 ASM。如果你的副本库也用 ASM，这行可以改成对应的 ASM 路径。
restore 完成后执行SWITCH DATABASE TO COPY，让控制文件正式指向新路径，然后开始 recover：
rman target / # 让控制文件切换到 restore 出来的新文件 SWITCH DATABASE TO COPY; 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; -- ... 释放通道 }手册在这里给了一个很实用的技巧：recover 到某个时间点后，可以alter database open read only打开看看数据对不对，如果要继续往前追归档，就shutdown abort; startup mount;再跑一次 recover。这样能分阶段验证，不用一次性追到最新。追归档时如果报RMAN-06054: media recovery requesting unknown archived log，说明归档链断了，需要list backup of archivelog from time 'sysdate-1';查一下备份里到底有哪些归档，缺的那段得从生产库补过来。
4. DBUA 升级执行与预检查：图形界面之外，静默模式才是生产首选
副本库恢复好、能 mount 之后，才轮到 DBUA 登场。手册提到 DBUA 支持静默方式（参考 MOS Doc ID 2548985.1），这点对生产环境特别重要——图形界面在跳板机、无 X11 的服务器上根本起不来，静默模式才是常态。
4.1 升级前的预检查：别跳过 preupgrade 脚本
DBUA 自己会跑预检查，但我习惯在启动 DBUA 之前先手工跑一遍官方预升级脚本，把问题提前暴露出来。11.2.0.4 升 19C，预升级脚本在 19C 的 ORACLE_HOME 下：
# 在源库（副本库）上执行 19C 自带的预升级脚本 $ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/rdbms/admin/preupgrade.jar \ FILE TEXT DIR /home/oracle/preupgrade # 脚本会生成 preupgrade.txt 和 fixup 脚本，重点看这几类 # 1. 需要手工处理的：比如已废弃参数、不支持的数据类型 # 2. 需要执行的 fixup SQL：按提示在源库上跑 # 3. 警告项：比如 OLAP、XDB 等组件状态预升级脚本的输出里，我最关注三类：一是RECOMMENDED ACTIONS里要求手工改的，比如sec_case_sensitive_logon、audit_trail这类参数；二是fixup目录下生成的 SQL，通常要在源库上执行完再升级；三是组件检查，如果源库里装了 19C 已不支持的组件，得先处理掉。手册摘要里专门提到“检查脚本生成的日志和警告”，说的就是这个环节，跳过它直接点 DBUA，很多问题会在升级中途才爆出来。
4.2 静默模式跑 DBUA：参数怎么给
图形界面下 DBUA 会一步步问你源库、目标库、恢复选项，静默模式则把这些都压成命令行参数。典型调用长这样：
# 在 19C 的 ORACLE_HOME 下执行 dbua 静默升级 $ORACLE_HOME/bin/dbua -silent \ -sid bsoft \ -oracleHome $ORACLE_HOME \ -sysPassword "your_sys_pwd" \ -sysmanPassword "your_sysman_pwd" \ -upgradeBy DBUA \ -recoveryAreaDestination /arch \ -diagnosticDest /u02/app/oracle \ -responseFile /home/oracle/dbua.rsp参数说明：-sid指定要升级的源库实例名；-oracleHome是 19C 的 Home，不是源库的；-recoveryAreaDestination指定恢复区，DBUA 升级前会自动做一次备份，空间要留够；-responseFile可以把所有参数写进响应文件，适合批量或重复执行。手册里源库db_name是 bsoft、db_unique_name是 bsoftsb，静默调用时-sid用的是实例名，别和 db_unique_name 搞混。
DBUA 执行过程中会做几件重活：检查源库状态、跑预升级、备份、启动升级、编译无效对象、更新数据字典。整个过程耗时取决于库的大小和对象数量，大库跑几个小时很正常。日志默认在$ORACLE_BASE/cfgtoollogs/dbua/下，升级卡住时第一时间去翻这个目录。
4.3 升级后的收尾：无效对象和时间区
DBUA 跑完不代表万事大吉。升级后必须确认两件事：无效对象数量和时区版本。无效对象用utlrp.sql重编译：
-- 升级后重编译所有无效对象 @?/rdbms/admin/utlrp.sql -- 查还有多少无效对象 SELECT COUNT(*) FROM dba_objects WHERE status = 'INVALID';时区版本是 11g 升 19C 的经典坑。19C 的时区文件版本比 11g 新，如果源库时区版本没跟上，带 TIMESTAMP WITH TIME ZONE 的表查询会报错。升级后检查：
SELECT * FROM v$timezone_file;如果版本落后，需要用DBMS_DST包做时区升级，这一步在 DBUA 里通常会自动处理，但升级后一定要复查一遍，别默认它一定成功。
5. 避坑与排查：升级路上最容易翻车的五个点
这一段是我从手册的报错记录和实际经验里挑出来的高频问题，每条按“现象 → 原因 → 解决”写，遇到时直接对号入座。
现象一：recover 时报RMAN-06054: media recovery requesting unknown archived log。原因：归档链断了，控制文件里记录的归档序列号在备份里找不到。手册里追到 sequence 25197 时就是这个错。 解决：先list backup of archivelog from time 'sysdate-1';看备份里实际有哪些归档，确认缺的是哪一段，从生产库把缺失的归档拷过来，再catalog注册后继续 recover。别硬追，缺归档时 recover 一定失败。
现象二：DBUA 预检查报一堆“不支持的数据类型”或“已废弃参数”。原因：11g 里用的一些老参数、老数据类型在 19C 里被废弃或改了默认值。 解决：跑 preupgrade 脚本时它会生成 fixup SQL，按提示在源库上执行。参数类的比如sec_case_sensitive_logon，要在升级前决定好是保持 FALSE 还是切到 TRUE，切 TRUE 前先确认应用支持大小写敏感密码。
现象三：升级后应用连不上，报密码验证失败。原因：19C 默认sec_case_sensitive_logon=TRUE，而 11g 时代密码是不区分大小写的，老应用的连接串里密码大小写可能和实际存储的不一致。 解决：升级后如果应用连不上，先查SELECT value FROM v$parameter WHERE name='sec_case_sensitive_logon';，必要时临时设回 FALSE 过渡，同时推动应用侧改密码。
现象四：副本库恢复时数据文件路径没改对，restore 报 ORA-01180 或找不到文件。原因：SET NEWNAME的路径写错，或者目标目录没提前建好。 解决：restore 前先确认/oradata/BSOFTSB/datafile/这类目录存在且有权限；SET NEWNAME里的%b占位符要保留，别手写成固定文件名，否则多个数据文件会互相覆盖。
现象五：DBUA 升级中途卡住或报 ORA-00600。原因：可能是某个组件状态异常、无效对象过多，或者源库本身有未处理的问题。 解决：先看$ORACLE_BASE/cfgtoollogs/dbua/下的日志定位到具体阶段；如果是组件问题，回到源库处理完再重跑 DBUA。副本库升级的好处在这时体现出来——直接重建副本重来，生产库不受影响。
6. 把升级做成可回退的流水线：我的分阶段追归档习惯
整套流程里，我觉得最值得固化成习惯的，是手册里那个“分阶段追归档”的做法。它把一次性的、不可中断的升级，拆成了可以随时暂停、随时验证的多个时间点。
具体做法是：restore 先到一个较早的时间点（手册里是 02:00:00），recover 到 07:00:00，open read only验证数据，确认没问题再shutdown abort; startup mount;继续追到 12:00:00，再验证，直到追到备份所能恢复的最后时间。每一步之间都可以停下来检查，而不是一口气追到最新才发现某个环节错了。
# 分阶段追归档的标准动作 # 1. 追到某个时间点 run { SET UNTIL TIME "TO_DATE('2022-08-30:12:00:00', 'YYYY-MM-DD:HH24:MI:SS')"; RECOVER DATABASE; } # 2. 只读打开验证 SQL> alter database open read only; -- 跑几个关键业务查询，确认数据对得上 # 3. 要继续追就关掉重来 SQL> shutdown abort; SQL> startup mount; # 4. 再跑一次 recover，不设 UNTIL 就是追到归档尽头这个习惯的好处是，你能清楚知道副本库当前停在哪个 SCN、哪个时间点，升级前对数据状态心里有底。DBUA 升级本身是不可逆的，但副本库的恢复过程完全可逆——追过头了，重建副本重来一遍就行。
从那以后我每次做跨版本升级，都强制走一遍“生产库全备 → 副本库分阶段恢复 → 只读验证 → DBUA 静默升级 → 无效对象和时区复查”这条链路，哪怕库再小也不省步骤。升级这件事，省下的每一步最后都会以另一种方式还回来。希望这套流程能帮到你，少踩几个我踩过的坑。
本文还有配套的精品资源，点击获取
