简介：《Oracle 11g 到 19C 数据库升级详尽指导手册》面向具备一定运维能力的数据库管理员，聚焦利用 DBUA 将 11g 单机库安全迁移至 19C 的维护场景。内容覆盖前期备份与恢复、升级路线与环境核对、图形及静默升级方式、必要参数调整，以及检查脚本日志和警告等关键注意事项，并给出常见故障的处理思路，便于读者按顺序核对命令细节、降低割接风险。资源包共 1 个 PDF 文件，大小约 3.18MB，适合作为升级前预演和现场操作时的速查材料。已有 1361 人学习，可帮助 DBA 结合 MOS 参考文档梳理从 11.2.0.4 到 19.x 的完整流程，提前发现兼容性与回退准备中的薄弱环节。
1. 整理这份 Oracle 11g 数据库升级运维指南时，我先不急着点 Oracle 19C DBUA 的下一步
整理这份 Oracle 11g 数据库升级运维指南时，我先不急着点 Oracle 19C DBUA 的下一步。真正卡人的往往不是图形界面，而是源库小版本、操作系统和恢复环境这三笔账：11.2.0.3 不能直接上 19C，Linux 6 上的 11g 也不能硬装 19C，DBUA 只负责升级动作，不负责替你补版本路线。
这次用的是 11.2.0.4.201020（补丁 31537677）恢复到升级机，再通过 19C 的 DBUA 升到 19.14.0.0.220118。源库保留不动，升级机失败还能回退。适合已经能管 11g 实例、准备把单机库迁到 19C 的运维读者，新手照着能走，熟手重点看版本取舍和恢复时间点。
2. 升级前环境准备：Oracle 19C 软件、11g 恢复 Home 和 Linux 7 检查
2.1 主机与版本路线核对
这套升级不是把 11g 的ORACLE_HOME换个路径就完事。升级机上要同时存在两个 Home：一个与源库同版本、同补丁的 11g Home，用来把源库备份恢复过来；另一个是 19C Home，用来跑 DBUA。源库继续保留，升级机只做恢复和升级，失败时把业务切回源库，这是最省心的后悔药。
| 角色 | 版本 | ORACLE_HOME | 说明 |
|---|---|---|---|
| 源库 | 11.2.0.4.201020（31537677） | 源库原路径 | 保留不动，用于回退 |
| 升级机恢复 Home | 11.2.0.4 + 同补丁 | /u02/app/oracle/product/11.2.0/db | 只用于恢复源库 |
| 升级机目标 Home | 19.14.0.0.220118 | /u01/app/oracle/product/19.14.0/db_1 | DBUA 从这里启动 |
| 升级机 | Linux 7.9 x86_64 | 示例地址192.0.2.10 | 19C 最低要求 Linux 7 |
19C 对操作系统的最低要求是 Linux 7。源库如果还在 Linux 6，不要在原机硬装 19C，常见做法是准备一台 Linux 7 新机，把 11g 备份恢复到新机的 11g Home，再用新机的 19C Home 执行 DBUA。版本路线也要先看表：11.2.0.4 及以上可以直接升 19.x；11.2.0.1、11.2.0.2、11.2.0.3 要先到 11.2.0.4；10.2.0.2 到 10.2.0.5 要先到 11.2.0.4 或 12.1.0.2；9.2.0.8 及更早要先到 11.2.0.4。DBUA 不会帮你跨过中间版本，先决条件检查这一关就会拦下来。
| 源库版本 | 升级路径 | 目标 |
|---|---|---|
| 11.2.0.4 及以上 | 直接升级 | 19.x |
| 11.2.0.1 / 11.2.0.2 / 11.2.0.3 | 先到 11.2.0.4 | 19.x |
| 10.2.0.2 至 10.2.0.5 | 先到 11.2.0.4 或 12.1.0.2 | 19.x |
| 12.1.0.1 | 先到 12.1.0.2 或 12.2.0.1 | 19.x |
| 9.2.0.8 及更早 | 先到 11.2.0.4 | 19.x |
注意：升级机上的 11g Home 不要图省事用低补丁版本恢复高补丁源库，数据文件头和回滚段兼容问题排查起来很费时间，版本和补丁对齐更稳。
2.2 安装 Oracle 19C 软件：只装软件不建库
19C 软件安装时选“只安装软件”，不要顺手建库。DBUA 要接管的是恢复过来的 11g 实例，不是新建的 19C 库。安装介质解压到临时目录，用响应文件静默安装，下面命令里的路径按自己的环境替换。
# 以 oracle 用户执行，进入 19C 安装介质目录 cd /soft/19c ./runInstaller -silent \ -responseFile /home/oracle/19c_install.rsp \ -ignorePrereqFailure # 安装完成后 root 执行两个脚本 /u01/app/oraInventory/orainstRoot.sh /u01/app/oracle/product/19.14.0/db_1/root.sh-responseFile指向提前改好的响应文件，-ignorePrereqFailure只建议在明确知道某条先决条件不影响本次升级时使用，否则先决条件失败就停下来看日志。安装响应文件里最关键的是安装选项、ORACLE_HOME、ORACLE_BASE 和操作系统组，常见项如下。
| 响应文件控制项 | 取值示例 | 说明 |
|---|---|---|
| 安装选项 | INSTALL_DB_SWONLY | 只装软件，不建库 |
| ORACLE_BASE | /u01/app/oracle | 19C 基础目录 |
| ORACLE_HOME | /u01/app/oracle/product/19.14.0/db_1 | DBUA 从这里启动 |
| 操作系统组 | oinstall、dba | 按主机实际组名填写 |
| 安装日志 | /u01/app/oraInventory/logs | 失败先看 installActions 日志 |
root.sh必须用 root 执行，执行完再回到 oracle 用户检查补丁。19C Home 装好后不要急着建监听，先把 11g 恢复库跑通，后面 DBUA 会关闭并重启实例，监听等到升级完成再统一切到 19C Home 更稳。
export ORACLE_HOME=/u01/app/oracle/product/19.14.0/db_1 export PATH=$ORACLE_HOME/bin:$PATH $ORACLE_HOME/OPatch/opatch lspatches $ORACLE_HOME/bin/sqlplus -Vopatch lspatches用来确认 19C 补丁版本，sqlplus -V确认客户端工具版本。两个 Home 并存时最怕环境变量串台，我习惯给 11g 和 19C 各写一个 env 文件，执行哪一步就 source 哪一个，不要在一个会话里来回 export。
2.3 准备 11g 恢复 Home 与参数文件目录
恢复源库要用 11g Home，先确认补丁和源库一致。下面的检查命令在升级机的 11g 环境里执行。
export ORACLE_HOME=/u02/app/oracle/product/11.2.0/db export PATH=$ORACLE_HOME/bin:$PATH $ORACLE_HOME/OPatch/opatch lspatches | grep -E '31537677|11.2.0.4' sqlplus -Vopatch lspatches输出里能看到 31537677 才说明恢复 Home 与源库补丁对齐。sqlplus -V只验证工具可用，不代表实例已启动。接下来建好审计目录、控制文件目录和数据文件目录，目录权限归 oracle 用户。
mkdir -p /u02/app/oracle/admin/srcdbupg/adump mkdir -p /oradata/srcdbupg/controlfile mkdir -p /oradata/srcdbupg/datafile mkdir -p /arch chown -R oracle:oinstall /u02/app/oracle/admin/srcdbupg /oradata/srcdbupg /arch参数文件从源库备份的 spfile 还原后修改，下面只列必须改的路径和库名，内存、processes、sessions 按源库原值保留并核对目标机资源，不要照抄别人的机器。
# 恢复库 pfile 关键项，库名和路径使用虚构代称 *.db_name='srcdb' *.db_unique_name='srcdbupg' *.compatible='11.2.0.4.0' *.control_files='/oradata/srcdbupg/controlfile/control01.ctl' *.audit_file_dest='/u02/app/oracle/admin/srcdbupg/adump' *.diagnostic_dest='/u02/app/oracle' *.db_recovery_file_dest='/arch' *.db_recovery_file_dest_size=200G *.db_create_file_dest='/oradata' *.service_names='srcdb,srcdbupg' *.remote_login_passwordfile='exclusive' *.sec_case_sensitive_logon=FALSE *.undo_tablespace='UNDOTBS1'db_name保持源库名，db_unique_name给升级机一个不同名字，避免和源库重名。compatible在升级前先保持 11.2.0.4，升级完成后再评估是否调整。control_files、audit_file_dest、db_recovery_file_dest都指向升级机本地路径，路径必须先建好，否则启动会报 OSD 错误。
export ORACLE_HOME=/u02/app/oracle/product/11.2.0/db export ORACLE_SID=srcdb export PATH=$ORACLE_HOME/bin:$PATH sqlplus / as sysdba <<'EOF' startup nomount pfile='/home/oracle/pfile.ora'; create spfile='/u02/app/oracle/product/11.2.0/db/dbs/spfilesrcdb.ora' from pfile='/home/oracle/pfile.ora'; EOF先用 pfile 启动到 nomount，再从 pfile 生成 11g Home 下的 spfile。ORACLE_SID必须和db_name对应，spfile路径放在 11g Home 的dbs目录下。到这里只完成了参数文件，控制文件和数据文件还没恢复。
3. 源库备份恢复到升级机：RMAN 恢复参数文件、控制文件和归档追平
3.1 备份与恢复参数文件、控制文件
源库备份过程不在这里展开，但备份策略要能支撑升级机恢复：全备、归档日志、控制文件自动备份，备份片统一放到升级机可访问的/hisbak，并记录备份时间点。常见做法是先做一次全备加归档，再开始恢复，避免恢复过程中归档被删除。
# 源库侧常见备份动作，按自己的保留策略调整 rman target / <<'EOF' CONFIGURE CONTROLFILE AUTOBACKUP ON; BACKUP DATABASE PLUS ARCHIVELOG; BACKUP CURRENT CONTROLFILE FORMAT '/hisbak/SRCDB_CONT_%U.ctl'; EOFBACKUP DATABASE PLUS ARCHIVELOG会先归档当前日志再备份数据文件和归档，CONTROLFILE AUTOBACKUP ON保证控制文件有自动备份。控制文件单独再备一份，是给恢复阶段省事，后面restore controlfile from可以直接指到文件。
升级机上先恢复 spfile，再生成可编辑的 pfile。下面命令在 11g Home 环境执行。
export ORACLE_HOME=/u02/app/oracle/product/11.2.0/db export ORACLE_SID=srcdb export PATH=$ORACLE_HOME/bin:$PATH rman target / <<'EOF' startup nomount; restore spfile from '/hisbak/spfile_srcdb_20220830.ora'; EOF sqlplus / as sysdba <<'EOF' create pfile='/home/oracle/pfile.ora' from spfile; exit EOFstartup nomount只需要参数文件，不要求控制文件和数据文件存在。restore spfile from把源库 spfile 还原到 11g Home 的默认位置，再用create pfile from spfile导出文本，按 2.3 的路径改。改完 pfile 后重新生成 spfile，后续启动都走 spfile，避免每次手写 pfile 路径。
控制文件恢复要在 nomount 之后、mount 之前做。下面命令把控制文件恢复到 pfile 指定的control_files路径。
rman target / <<'EOF' restore controlfile from '/hisbak/SRCDB_CONT_20220830.ctl'; alter database mount; catalog start with '/hisbak/'; EOFrestore controlfile from指定控制文件备份片，alter database mount让实例读取控制文件，catalog start with把/hisbak下的备份片重新登记进控制文件。控制文件不是当前的时候，REPORT SCHEMA可能给出警告，这是正常现象，先把备份片 catalog 进来再继续。
rman target / <<'EOF' REPORT SCHEMA; EOFREPORT SCHEMA用来核对数据文件、临时文件清单和路径。如果输出里还是源库的 ASM 路径或旧路径，不要慌，下一步SET NEWNAME会统一改到升级机本地路径。这里重点看文件数量和表空间，确认没有漏掉业务数据文件。
3.2 restore database 的时间点与 newname
恢复数据文件时用SET NEWNAME把源库路径改到升级机，SET UNTIL TIME控制恢复到哪个时间点。下面示例先恢复到备份时间点附近，再通过 recover 往后续归档上追。
rman target / <<'EOF' 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; SET NEWNAME FOR DATABASE TO '/oradata/srcdbupg/datafile/%b'; SET UNTIL TIME "TO_DATE('2022-08-30:02:00:00','YYYY-MM-DD:HH24:MI:SS')"; RESTORE DATABASE; RELEASE CHANNEL C4; RELEASE CHANNEL C3; RELEASE CHANNEL C2; RELEASE CHANNEL C1; } EOFSET NEWNAME FOR DATABASE TO里的%b表示保留原文件名，只换目录，减少文件名冲突。SET UNTIL TIME是 restore 的时间上限，不是最终恢复时间；后面 recover 可以继续往后走。通道数量按备份片所在磁盘的吞吐调整，通道不是越多越好，I/O 打满后反而互相拖慢。
restore 完成后要让控制文件指向新文件，再执行 recover。下面示例先切到 copy，再追到更晚的时间点。
rman target / <<'EOF' SWITCH DATABASE TO COPY; 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; SET UNTIL TIME "TO_DATE('2022-08-30:07:00:00','YYYY-MM-DD:HH24:MI:SS')"; RECOVER DATABASE; RELEASE CHANNEL C4; RELEASE CHANNEL C3; RELEASE CHANNEL C2; RELEASE CHANNEL C1; } EOFSWITCH DATABASE TO COPY让控制文件正式使用 restore 出来的副本，少了这一步，后面打开数据库还会去找旧路径。RECOVER DATABASE应用归档和在线日志，SET UNTIL TIME控制追到哪个时间点。时间点不要一次追到源库当前时间，先追到一个可校验的中间点，打开只读确认数据文件一致，再继续追。
如果归档足够，可以再追一次到更晚时间。下面示例追到 12:00，实际业务窗口按自己的备份和归档情况改。
rman target / <<'EOF' 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; SET UNTIL TIME "TO_DATE('2022-08-30:12:00:00','YYYY-MM-DD:HH24:MI:SS')"; RECOVER DATABASE; RELEASE CHANNEL C4; RELEASE CHANNEL C3; RELEASE CHANNEL C2; RELEASE CHANNEL C1; } EOF每次 recover 后看 RMAN 输出里应用的归档序列和 SCN，确认没有跳号。归档备份片和在线归档都可以作为来源，catalog start with之后 RMAN 才能识别备份片里的归档。时间点越靠近源库当前时间，升级后业务验证越完整，但升级窗口也越长，取舍点在业务能接受的停写窗口。
3.3 read only 校验和继续追归档
数据文件恢复到一个阶段后，用只读方式打开，做一次文件头和基本查询校验。只读打开不会写数据文件，适合在升级前确认恢复库可用。
sqlplus / as sysdba <<'EOF' alter database open read only; select name, open_mode from v$database; select file#, name, status from v$datafile; select file#, name, status from v$tempfile; EOFopen read only成功后，v$database.open_mode显示READ ONLY，v$datafile里所有数据文件状态应为 online。此时可以跑几条业务只读 SQL，确认核心表能访问。只读打开后如果还要继续追归档，必须先关库再启到 mount，不能直接在 read only 状态做恢复。
sqlplus / as sysdba <<'EOF' shutdown abort; startup mount; EOF rman target / <<'EOF' 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; RECOVER DATABASE; RELEASE CHANNEL C4; RELEASE CHANNEL C3; RELEASE CHANNEL C2; RELEASE CHANNEL C1; } EOFshutdown abort在测试恢复库上可以用，生产库不要照搬。startup mount后继续RECOVER DATABASE，不写SET UNTIL TIME表示尽量追到最后一个可用归档。追到没有归档时，常见报错是RMAN-06054: media recovery requesting unknown archived log，意思是要某个序列的归档但备份里没有。先list backup of archivelog all看已有序列，再从源库补拷缺失归档，catalog start with后继续 recover。
rman target / <<'EOF' list backup of archivelog all; EOFlist backup of archivelog all的输出重点看线程号、序列号、低 SCN 和完成时间。缺的归档序列如果源库还在，直接从源库归档目录拷到/hisbak或/arch，再 catalog。不要在没有确认归档完整性的情况下强行打开读写，升级前的恢复库越干净，DBUA 阶段越少黑匣子。
4. DBUA 执行升级：19C Home 环境变量、图形界面和静默模式
4.1 升级前检查：监听、无效对象、时区、归档
DBUA 启动前先做一轮检查，别让无效对象和归档问题把升级窗口吃掉。下面 SQL 在恢复库的 11g 环境执行，确认版本、组件、无效对象和归档模式。
-- 在恢复库 11g 环境执行 select banner from v$version; select name, open_mode, log_mode from v$database; select comp_name, status, version from dba_registry; select count(*) invalid_count from dba_objects where status = 'INVALID'; select destination, status, error from v$archive_dest where destination is not null;v$version确认源库版本；v$database.log_mode应为 ARCHIVELOG；
本文还有配套的精品资源，点击获取
