简介这份《Oracle 11g 到 19C 数据库升级详尽指导手册》面向具备一定运维能力的数据库管理员DBA聚焦于借助DBUADatabase Upgrade Assistant工具将Oracle 11g安全迁移至19C这一典型维护场景。内容围绕前期备份与恢复、升级流程、必要配置调整及注意事项展开并强调检查脚本生成的日志与警告同时附有多个故障解决方案帮助应对升级中可能出现的异常情形。资源包共1个PDF文件大小约3.18MB以图文与命令细节为主便于按步骤对照执行。目前已有1350人学习下载适合希望提升数据库性能与安全性、顺应未来软件架构趋势的运维人员参考尤其适合需要严格把控升级顺序与命令细节的读者。1. 一次 11g 升 19C 的翻车复盘为什么我坚持用 DBUA 而不是手动脚本去年帮一个朋友处理过一套跑了七八年的 Oracle 11.2.0.4 单机库业务催着要升到 19C理由很直接——11g 官方早就不出补丁了安全审计过不去。他一开始想手动敲 catupgrd.sql结果跑到一半报错回退又没做干净最后只能从备份重来。这件事让我更加确信对单机库来说DBUADatabase Upgrade Assistant才是那个能让你少熬两个通宵的选择。它把前置检查、参数调整、组件升级、时区文件更新这些步骤串成一条流水线图形界面点几下或者静默模式跑一条命令中间哪一步卡住了日志也给你留得清清楚楚。这篇笔记就按我实际操作的顺序把 11.2.0.4 升 19.14 的完整过程拆开包括环境怎么备、RMAN 怎么恢复、DBUA 怎么配、装完怎么验证。如果你手里也有一套 11g 等着升照着走一遍至少能避开我踩过的那些坑。2. 升级前的环境准备版本路线和主机检查2.1 先确认你的 11g 能不能直接升 19COracle 的升级路线不是随便跳的官方文档里写得很死。11.2.0.4 及以上版本可以直接升到 19.x但 11.2.0.1 到 11.2.0.3 必须先升到 11.2.0.4 才能再往 19C 走。10.2.0.2 到 10.2.0.5 的库中间得先到 11.2.0.4 或者 12.1.0.2。9.2.0.8 及更早的版本同样要先落到 11.2.0.4。12.1.0.1 不能直接升 19C得先到 12.1.0.2 或 12.2.0.1。我这次操作的源库是 11.2.0.4.201020补丁号 31537677属于可以直接升的范围。提示查源库版本用select * from v$version;确认第四位补丁号。如果低于 11.2.0.4先打补丁再考虑升级。2.2 主机版本这道坎Linux 6 必须换机19C 对操作系统的要求最低是 Linux 7。我见过有人试图在 RHEL 6 上硬装 19C结果连 GI 都起不来。如果你源库跑在 Linux 6 上别折腾了直接准备一台 Linux 7 的新主机把 19C 装上去再用 RMAN 把源库恢复过来。我这次目标库用的是 RHEL 7.9源库和目标库在同一台机器上通过不同 ORACLE_HOME 隔离——源库在/u02/app/oracle/product/11.2.0/db目标库 19C 装在/u01/app/oracle/product/19.14.0/db_1。这种同机异 Home 的做法适合测试升级生产环境建议分开主机避免资源争抢。2.3 源库备份与目标库恢复策略源库是生产库不能直接在上面做升级实验。我的做法是用 RMAN 把生产库备份恢复到目标库环境保留生产库原样不动万一升级失败还能回退。恢复的时候可以只恢复到某个时间点后面通过追归档把时间往前推。具体恢复步骤在下一章展开。这里先记住一个原则目标库的 DB_NAME 可以和源库不同但 DBID 必须一致否则 RMAN 不认。我这次源库 db_name 是 bsoft目标库 db_unique_name 设为 bsoftsbDBID 通过恢复控制文件自动带过来。2.4 检查表空间和组件状态升级前在源库跑一遍dbupgdiag.sql或者手动查dba_registry看看有没有无效组件。常见的有 OLAP、XDB、OWB 这些如果状态是 INVALID 或者 LOADED升级过程中 DBUA 会报错。我一般会先跑-- 检查组件状态 select comp_id, comp_name, status, version from dba_registry; -- 检查无效对象 select owner, object_name, object_type from dba_objects where statusINVALID;如果发现无效对象能编译的先编译编译不过的记下来升级后可能自动修复也可能需要手动处理。另外确认timezone_file_version11g 的时区文件版本通常比较老19C 要求至少 version 32DBUA 会自动更新但更新前会提示你确认。3. 用 RMAN 把生产库恢复到升级环境3.1 恢复参数文件并重建 SPFILE目标库上先 source 一下 11g 的环境变量因为恢复用的是 11g 的 RMAN。我实际操作时先切到 oracle 用户然后source .bash_profile rman target /在 RMAN 里启动到 nomount从备份片恢复 spfileRMAN startup nomount; RMAN restore spfile from /hisbak/spfile_BSOFT_562120512_20220830_40444.ora;恢复出来的 spfile 是二进制文件直接改不方便先转成 pfileSQL create pfile/home/oracle/pfile.ora from spfile;然后编辑 pfile把路径参数改成目标库的实际路径。我这次改了几个关键项audit_file_dest指向/u02/app/oracle/admin/bsoftsb/adumpcontrol_files指向/oradata/bsoftsb/controlfile/control01.dbfdb_unique_name改成 bsoftsbservice_names加上 bsoftsb。改完用 pfile 启动到 nomount再重建 spfileSQL 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;这一步的逻辑是spfile 里的路径是源库的直接拿来用会找不到文件。先转 pfile 改路径再生成新的 spfile目标库才能正常启动。3.2 恢复控制文件并加载备份控制文件恢复用 RMAN 的restore controlfile命令RMAN restore controlfile from /hisbak/BSOFT_CONT_562120512_20220830_40443.ctl; RMAN sql alter database mount; RMAN catalog start with /hisbak/;catalog start with的作用是让 RMAN 扫描指定目录下的备份片把它们注册到控制文件里。如果不做这一步RMAN 不知道备份集的存在后续 restore 会报找不到备份。执行完可以用list backup;确认备份集已经识别。3.3 RESTORE 和 RECOVER 到指定时间点恢复数据库时我用了 16 个通道并行加快速度。注意SET NEWNAME把数据文件重定向到目标库的路径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; -- 省略其他 RELEASE }RESTORE 完成后执行SWITCH DATABASE TO COPY;让控制文件指向新路径的数据文件。然后 RECOVERrun { 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 }如果归档足够可以继续往前追。我后来又追到 12:00:00然后alter database open read only;确认数据一致性。如果要再次追归档先shutdown abort; startup mount;再跑 RECOVER。最后一次尝试恢复到备份所能恢复的最后时间时RMAN 报RMAN-06054: media recovery requesting unknown archived log说明归档链断了缺 sequence 25197。这时候用list backup of archivelog from time sysdate-1;查一下备份集里有哪些归档确认缺失的序列号是否真的没有备份。如果确实没有就只能恢复到当前可用的最后时间点。4. DBUA 图形化升级从启动到参数配置4.1 启动 DBUA 前的环境变量切换恢复完成后目标库是 11g 的 ORACLE_HOME 在跑。要升级到 19C得先切到 19C 的环境变量export ORACLE_HOME/u01/app/oracle/product/19.14.0/db_1 export PATH$ORACLE_HOME/bin:$PATH export ORACLE_SIDbsoft然后确认监听器状态19C 的监听器要能同时识别 11g 和 19C 的实例。我一般用 19C 的lsnrctl启动监听配置里加上两个 SID 的描述。DBUA 启动时会自动检测当前实例如果监听不通它会提示你。4.2 DBUA 界面里的关键选项执行dbua命令启动图形界面。第一步选要升级的数据库DBUA 会自动列出当前 ORACLE_SID 对应的实例。第二步是升级选项有几个关键选择Upgrade Timezone Version默认勾选19C 要求时区版本至少 32建议保持勾选。Recompile Invalid Objects升级后自动编译无效对象勾选。Backup DatabaseDBUA 会问你要不要先做备份。我一般选“No”因为前面已经用 RMAN 恢复了一套再备份一次太耗时。但生产环境建议选“Yes”多一层保险。Parallel Upgrade根据 CPU 核数设置并行度我设了 4太高会拖慢 I/O。第三步是网络配置确认监听器端口和 service name。第四步是恢复选项如果升级失败DBUA 可以自动回退到升级前的状态前提是你之前选了备份。第五步是管理选项比如是否启用 EM Express按需勾选。4.3 静默模式一条命令搞定如果服务器没有图形界面或者你想把升级脚本化DBUA 支持静默模式。参考 MOS 文档 Doc ID 2548985.1命令格式大致如下$ORACLE_HOME/bin/dbua -silent \ -sid bsoft \ -oracleHome $ORACLE_HOME \ -sysDBAUserName sys \ -sysDBAPassword your_password \ -upgradeTimezoneVersion true \ -recompileInvalidObjects true \ -parallelUpgradeDegree 4参数说明-sid指定要升级的实例名-oracleHome是 19C 的 ORACLE_HOME-sysDBAUserName和-sysDBAPassword用于连接源库-upgradeTimezoneVersion控制是否更新时区文件-parallelUpgradeDegree设置并行度。静默模式跑完会在$ORACLE_BASE/cfgtoollogs/dbua/下生成日志升级结果看日志里的SUCCESS或FAILURE。4.4 升级过程中的日志监控DBUA 跑的时候别干等着开一个终端 tail 日志tail -f $ORACLE_BASE/cfgtoollogs/dbua/bsoft/upgrade/upgrade.log日志里会显示当前执行到哪个阶段比如Pre-Upgrade Checks、Database Upgrade、Post-Upgrade Actions。如果卡在某个阶段超过预期时间先看日志有没有报错。常见的是表空间不足或者归档目录满了提前清理一下。5. 升级避坑五条血泪经验5.1 ORA-00257 归档目录满导致升级中断现象DBUA 跑到一半报ORA-00257: archiver error. Connect internal only, until freed升级挂起。原因源库的db_recovery_file_dest_size设了 200G但实际归档量超过了限制或者归档目录所在文件系统满了。解决升级前先查select * from v$recovery_file_dest;和df -h确认归档空间充足。如果不够要么扩大db_recovery_file_dest_size要么手动删掉过期归档。我一般会在升级前把归档备份到磁带或另一块盘然后delete archivelog all completed before sysdate-1;清掉旧的。5.2 时区文件版本不匹配现象DBUA 前置检查报Timezone version 14 is lower than required 32。原因11g 的时区文件版本太老19C 要求至少 32。解决DBUA 会自动更新时区文件但更新前会提示你确认。如果手动升级需要先跑$ORACLE_HOME/bin/tzupgrade脚本。注意更新时区文件后TIMESTAMP WITH TIME ZONE类型的数据会重新计算建议在业务低峰期做。5.3 无效对象太多导致升级超时现象DBUA 在Recompile Invalid Objects阶段跑了几个小时没结束。原因源库里有大量无效对象比如失效的存储过程、视图、同义词DBUA 逐个编译很慢。解决升级前先查dba_objects里statusINVALID的对象能手动编译的先编译。用utlrp.sql跑一遍?/rdbms/admin/utlrp.sql如果还有无效的记下来升级后可能自动修复也可能需要手动处理。5.4 监听器配置错误导致 DBUA 连不上实例现象DBUA 启动后提示Could not connect to the database。原因19C 的监听器没有配置 11g 实例的静态注册或者local_listener参数指向了错误的地址。解决检查$ORACLE_HOME/network/admin/listener.ora加上SID_LIST_LISTENER (SID_LIST (SID_DESC (SID_NAME bsoft) (ORACLE_HOME /u02/app/oracle/product/11.2.0/db) ) )然后lsnrctl reload。另外确认local_listener参数show parameter local_listener;如果为空设成(ADDRESS(PROTOCOLTCP)(HOST192.168.6.132)(PORT1521))。5.5 升级后 EM Express 端口冲突现象升级完成后 EM Express 起不来报端口被占用。原因19C 的 EM Express 默认用 5500 端口如果之前有别的服务占了就起不来。解决查select dbms_xdb_config.gethttpsport() from dual;看当前端口如果冲突用dbms_xdb_config.sethttpsport(5501);改一个空闲端口。改完重启监听。6. 升级后验证跑通这五步才算完升级完别急着交差我一般会按下面五步走一遍确认数据库真的没问题。第一步查版本和组件状态select * from v$version; select comp_id, comp_name, status, version from dba_registry;19C 的版本号应该显示19.14.0.0.0所有组件状态应该是VALID。如果有INVALID的跑utlrp.sql再查一次。第二步检查时区文件版本select * from v$timezone_file;version应该大于等于 32。如果还是旧的说明时区更新没成功需要手动跑tzupgrade。第三步验证无效对象select count(*) from dba_objects where statusINVALID;理想结果是 0。如果还有查具体是哪些select owner, object_name, object_type from dba_objects where statusINVALID;能编译的编译编译不过的看是不是业务上已经废弃的对象。第四步跑一遍 DBUA 生成的验证脚本DBUA 升级完成后会在$ORACLE_BASE/cfgtoollogs/dbua/下生成一个postupgrade.log里面列出了需要手动检查的项。我一般会照着这个日志逐条确认比如utlrp.sql是否跑过、catuppst.sql是否执行成功。第五步业务连接测试用应用连接串连一下跑几条典型 SQL确认查询和写入都正常。我习惯用sqlplus连上去跑一个select count(*) from 业务表;再做一个insert和rollback确认 DML 没问题。注意升级后第一次启动数据库可能会比较慢因为要加载新的组件和参数。如果超过 10 分钟还没起来查alert.log看有没有报错。从那以后我每次升级完都会强制走一遍这五步验证哪怕 DBUA 提示成功也不跳过。数据库这东西表面看着好了底下可能还藏着没编译完的对象或者没更新的参数。希望这套流程能帮你少走点弯路。本文还有配套的精品资源点击获取