Oracle 11g 升级 19C 实战：DBUA 与 RMAN 恢复避坑指南

简介面向具备一定运维能力的数据库管理员DBA的实操型升级手册围绕使用 DBUA 工具将 Oracle 11g 单机库迁移至 19C 这一典型场景展开重点解决旧版本停止补丁更新后如何安全升级、如何控制回退风险的问题。内容涵盖升级路线与主机版本要求说明、前期 RMAN 备份并恢复到目标库时的参数文件调整、DBUA 图形与静默两种执行方式、升级后必要的配置修改并附有 MOS 参考文档编号与多个故障处理方案强调逐步核对脚本生成的日志与警告信息。资源包共 1 个 PDF 文件约 3.18MB单个文件即完整手册便于离线查阅与打印对照。已有 1361 人学习下载适合作为升级前评估与现场操作的参照帮助读者理清从备份、恢复到升级验证的完整链路降低迁移过程中的试错成本。1. 版本账先算清楚11.2.0.4 是直升级 19C 的唯一起点上周帮人看一台要升级的 11.2.0.4 单机库对方已经把 19C 软件装好DBUA 也点到了第三步结果卡在预检查那页不动。翻日志才发现源库 COMPATIBLE 参数还停在 11.2.0.3升级脚本连组件校验都过不去。这类情况在 11g 到 19C 的路上特别多因为中间跨了 12.1、12.2、18 三个大版本官方允许直接升到 19C 的源库只有 11.2.0.4 及以上11.2.0.1 到 11.2.0.3、11.1.0.6/11.1.0.7、10.2 全系、9.2.0.8 及更早都得先补到 11.2.0.4 或 12.1.0.2 再走第二跳。正在做数据库升级、准备用 DBUA 图形化那条路把 Oracle 11g 升到 19C 的人先把版本账、主机账、回退账算清后面每一步才不会白跑。2. 目标环境落地RHEL 7.9 上装 19.14 并隔离两个 ORACLE_HOME源库是生产环境不能拿它做升级试验。稳妥的做法是另备一台机器装 19C 软件把生产库的 RMAN 备份恢复过来在副本上把升级跑通生产库原样留着当后悔药。这次的环境是这样源库 11.2.0.4 单机目标机装 RHEL 7.9、19C 软件版本 19.14.0.0.220118。两个 ORACLE_HOME 我刻意放在不同挂载点19C 在/u01/app/oracle/product/19.14.0/db_111g 那份留在/u02/app/oracle/product/11.2.0/db回退时互不干扰。角色主机系统主机名数据库版本ORACLE_HOME源库生产RHEL 7.9erpdb0111.2.0.4.201020 (31537677)/u02/app/oracle/product/11.2.0/db升级库目标RHEL 7.9oracle19c19.14.0.0.220118/u01/app/oracle/product/19.14.0/db_1提示文中的库名、主机名、备份文件名都做过脱敏替换路径结构保持一致照着自己环境替换即可。2.1 操作系统与内存的最低门槛19C 对操作系统的要求比 11g 硬得多最低是 Linux 7。如果源库主机还跑在 Linux 6 上DBUA 那条路在物理上就不成立必须先准备一台 Linux 7 的新机把库搬过去再升。这一条不满足后面所有步骤都是空谈。装机前我一般先跑一遍体检命令把版本、内核、内存、挂载点余量一次性看清楚。# 系统与资源体检装 19C 前必看 cat /etc/redhat-release # 必须是 7.x 及以上 uname -r # 3.10.0-1160 这类内核较稳 free -g # 物理内存对照 pfile 里的 SGA/PGA 预留 df -h /u01 /u02 /oradata /arch # 软件、数据、归档三个挂载点都要留足 grep -E memlock|nofile|nproc /etc/security/limits.conf命令本身不复杂关键是看返回值怎么判断。free -g那一列要能覆盖从生产带过来的sga_max_size和pga_aggregate_target之和这台环境的 pfile 里sga_max_size是 64G、memory_max_target是 120G目标机物理内存低于 128G 就要在参数文件里往下调否则startup nomount直接报 ORA-27102 内存不够升级还没开始就先翻车。df -h看的是/archDBUA 跑升级期间归档量会明显上涨db_recovery_file_dest_size该给的余量不能抠我吃过一次归档空间打满导致升级卡在 92% 的亏后面每次都会把它单列出来核一遍。2.2 19C 软件静默安装与两个 HOME 的隔离19C 只装软件、不建库用响应文件静默装最省事。软件清单里选INSTALL_DB_SWONLY路径指到/u01/app/oracle/product/19.14.0/db_1ORACLE_BASE统一到/u01/app/oracle。这里有个容易写错的地方ORACLE_HOME的父目录必须能对上ORACLE_BASE两者混写会让 root.sh 跑到一半报目录权限异常。# 19c_swonly.rsp 关键片段 oracle.install.optionINSTALL_DB_SWONLY UNIX_GROUP_NAMEoinstall INVENTORY_LOCATION/u01/app/oraInventory ORACLE_HOME/u01/app/oracle/product/19.14.0/db_1 ORACLE_BASE/u01/app/oracle oracle.install.db.InstallEditionEE oracle.install.db.OSDBA_GROUPdba oracle.install.db.OSOPER_GROUPoper oracle.install.db.OSBACKUPDBA_GROUPdba oracle.install.db.OSDGDBA_GROUPdba oracle.install.db.OSKMDBA_GROUPdba oracle.install.db.OSRACDBA_GROUPdba各参数的作用INSTALL_DB_SWONLY决定了只铺二进制、建库留给后面的 DBUAOSDBA_GROUP这几个组要和系统里id oracle的结果完全一致写成dba而实际组名是oracle之类安装到最后一步会因组成员校验失败而回滚INVENTORY_LOCATION建议单独放一层避免和 11g 的清单目录混用两个 home 共用一个 oraInventory 在打补丁时容易互相牵制。执行安装同样是一条命令跑完再用 root 执行脚本# 静默安装 19C 软件 /u01/app/oracle/product/19.14.0/db_1/runInstaller -silent -waitforcompletion \ -responseFile /home/oracle/19c_swonly.rsp -ignorePrereqFailure # 装完后用 root 跑一次两个脚本都别落下 /u01/app/oraInventory/orainstRoot.sh /u01/app/oracle/product/19.14.0/db_1/root.sh-waitforcompletion让命令前台等结束方便看返回码-ignorePrereqFailure只在明确知道缺哪个包、并且准备装完立刻补的情况下才用生产机上我一般不加宁可先补包。装完不要急着往下走先确认 19C 的$ORACLE_HOME/bin/sqlplus能起来、opatch lspatches能读出补丁列表说明 home 是健康的。2.3 升级前检查脚本preupgrade.jar 与 dbupgdiag.sql19C 已经不推utlu112i.sql那套了正式检查用目标 home 里自带的preupgrade.jar在源库上跑。它会输出三份东西一份问题清单、一份升级前 fixup 脚本、一份升级后 fixup 脚本。我一般先跑TEXT模式看结论确认没有致命项再往下走。# 在源库执行JDK 用 19c home 自带的避免版本不匹配 cd /home/oracle $ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/rdbms/admin/preupgrade.jar TEXT # 同时在源库收集字典健康信息出问题时这是关键证据 sqlplus -S / as sysdba ?/rdbms/admin/dbupgdiag.sqlpreupgrade.jar的输出默认落在$ORACLE_BASE/cfgtoollogs/SID/preupgrade/下里面有preupgrade.log、preupgrade_fixups.sql、postupgrade_fixups.sql三个文件。日志里要重点盯三类COMPATIBLE参数是否满足、DBA_REGISTRY里有没有非 VALID 的组件、时区文件版本是否落后。dbupgdiag.sql生成的是字典诊断报告升级失败时提交问题基本都要靠它先跑一遍存着不亏。preupgrade_fixups.sql在源库执行postupgrade_fixups.sql留到升级完再跑这两个别弄反。执行前把库开成 RESTRICTED 会话模式避免业务连接在改对象时插进来。-- 升级前固定动作干净关机、清回收站、编译无效对象 shutdown immediate; startup restrict; purge dba_recyclebin; ?/rdbms/admin/utlrp.sql select count(*) from dba_objects where status INVALID;purge dba_recyclebin是为了避免回收站里的对象被升级脚本扫描到utlrp.sql编译一遍无效对象最后那条计数最好归零。做不到零也不用慌但要知道剩的是哪些——如果集中在业务自建包上升级后还要再编一次。3. 把生产库搬过来RMAN 恢复 spfile、控制文件与追归档升级环境准备好之后下一步是把生产库的数据弄过来。这一步用 RMAN 做思路是先恢复到某个较早的时间点只要能起来剩下的靠追归档往前推。这样做的好处是恢复阶段不用等生产库停机升级窗口里只需要把最后一段归档拷过来追平窗口能压得很短。库名这里用erp唯一名用erpup和源库区分开。3.1 恢复参数文件与控制文件第一步永远是参数文件。从备份里把 spfile 捞出来转成 pfile 之后按目标机的实际情况改路径再反向生成一份新的 spfile。这一步不改干净后面startup mount一定报控制文件找不到。# 起实例到 nomount准备恢复 spfile [oracleoracle19c:~]$ source .bash_profile [oracleoracle19c:~]$ rman target / RMAN startup nomount; RMAN restore spfile from /hisbak/spfile_ERPDB_562120512_20220830_40444.ora;-- 转 pfile 出来改路径再生成新的 spfile SQL create pfile/home/oracle/pfile.ora from spfile;pfile 里要动手的地方集中在路径类参数上下面这几项是每次都要核的# /home/oracle/pfile.ora 关键项其余略 *.db_nameerp *.db_unique_nameerpup *.audit_file_dest/u02/app/oracle/admin/erp/adump *.control_files/oradata/erpup/controlfile/control01.dbf *.db_create_file_dest/oradata *.db_recovery_file_dest/arch *.db_recovery_file_dest_size200G *.diagnostic_dest/u02/app/oracle *.sga_max_size68719476736 *.sga_target68719476736 *.pga_aggregate_target8474591232 *.processes6000 *.sessions3305 *.undo_tablespaceUNDOTBS1 *.sec_case_sensitive_logonFALSEdb_name保持和生产一致db_unique_name换成新的这样回退时两份库不会撞名audit_file_dest、control_files、db_create_file_dest全部指向目标机的目录原样照抄生产路径是最常见的错误目录不存在时实例根本起不来。sga_max_size和pga_aggregate_target这两个值是从生产带过来的目标机内存不够就按 2.1 节的判断往下调。改完 pfile 之后建目录、起实例、生成新 spfilemkdir -p /u02/app/oracle/admin/erp/adump mkdir -p /oradata/erpup/controlfile/SQL startup nomount pfile/home/oracle/pfile.ora; SQL create spfile/u02/app/oracle/product/11.2.0/db/dbs/spfileerp.ora from pfile/home/oracle/pfile.ora;注意这里生成的 spfile 放在 11g 那个 home 的dbs目录下因为此刻实例还是 11.2.0.4 版本必须用 11g 的二进制来启。19C 的 home 在这个时候只提供 DBUA 工具不参与启库。控制文件从备份集里恢复恢复到哪一步是有讲究的控制文件恢复出来的时间点决定了后面能追到多近恢复完要立刻mount并catalog备份目录让 RMAN 认识这些备份片。[oracleoracle19c:/hisbak]$ rman target / RMAN restore controlfile from /hisbak/ERPDB_CONT_562120512_20220830_40443.ctl; RMAN sql alter database mount; RMAN catalog start with /hisbak/;restore controlfile之后实例处于 nomount必须alter database mount才能看到数据文件列表catalog start with是让 RMAN 把目录下所有备份片登记进来不做这一步后面的restore database会报找不到备份。这一步做完可以REPORT SCHEMA看一眼数据文件清单确认文件数量和源库对得上。3.2 restore 与 recover把数据文件落到新路径数据文件在备份里记的是源库路径恢复时必须用SET NEWNAME重定向到目标机目录否则会出现大批文件已存在或者路径不存在的报错。这次的目标路径是/oradata/ERPUP/datafile/%b%b表示沿用原文件名只换目录可读性好。# 多通道并行恢复通道数按主机 CPU 和磁盘 IO 定这里给 16 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; ALLOCATE CHANNEL C5 DEVICE TYPE DISK; ALLOCATE CHANNEL C6 DEVICE TYPE DISK; ALLOCATE CHANNEL C7 DEVICE TYPE DISK; ALLOCATE CHANNEL C8 DEVICE TYPE DISK; ALLOCATE CHANNEL C9 DEVICE TYPE DISK; ALLOCATE CHANNEL C10 DEVICE TYPE DISK; ALLOCATE CHANNEL C11 DEVICE TYPE DISK; ALLOCATE CHANNEL C12 DEVICE TYPE DISK; ALLOCATE CHANNEL C13 DEVICE TYPE DISK; ALLOCATE CHANNEL C14 DEVICE TYPE DISK; ALLOCATE CHANNEL C15 DEVICE TYPE DISK; ALLOCATE CHANNEL C16 DEVICE TYPE DISK; SET NEWNAME FOR DATABASE TO /oradata/ERPUP/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 CHANNEL C1; }SET UNTIL TIME是这次恢复的时间边界选一个比备份完成时间略早的点保证数据文件是一致的SET NEWNAME FOR DATABASE对所有数据文件生效包括后来加的那些通道数不是越多越好16 个通道在普通 SAN 上已经接近带宽上限再加只会互相抢 IO。恢复时间主要取决于备份片大小和磁盘吞吐几十 G 的库一般几十分钟量级。恢复完数据文件用SWITCH DATABASE TO COPY把控制文件里的路径切到新位置然后进入 recover 阶段。rman target / 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; ALLOCATE CHANNEL C5 DEVICE TYPE DISK; ALLOCATE CHANNEL C6 DEVICE TYPE DISK; ALLOCATE CHANNEL C7 DEVICE TYPE DISK; ALLOCATE CHANNEL C8 DEVICE TYPE DISK; SET UNTIL TIME TO_DATE(2022-08-30:07:00:00,YYYY-MM-DD:HH24:MI:SS); RECOVER DATABASE; RELEASE CHANNEL C8; RELEASE CHANNEL C1; }SWITCH DATABASE TO COPY不做的话控制文件里记的还是生产路径recover 会一直去找不存在的文件。recover 的时间点可以分段往前推先到 07:00再追到 12:00每追一段都是增量应用归档代价比一次性追到最新更可控——万一中间某段归档损坏还能定位在哪一段断掉。3.3 只读打开与继续追归档恢复到一个候选时间点后先用只读方式打开验证一下这一步相当于试跑出问题不影响数据文件。SQL alter database open read only;只读能打开说明数据文件、控制文件、归档链在这一点是一致的。这时候可以连进去抽查几张核心表行数和生产对得上再决定要不要继续追。要再往前追归档必须先关库回到 mountSQL shutdown abort; SQL startup mount;然后重新跑一次RECOVER DATABASE不写SET UNTIL TIME就是把手上所有归档全部应用完一直追到归档的尽头。追到底时会看到类似这样的报错RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 25197 and starting SCN of 18157927920这条不是故障是正常的归档用完了信号说明手上能追的已经追到极限。要判断还差多少用list backup of archivelog from time sysdate-1看最后一段归档的序号和时间再和源库当前的序号对一下差得不多就可以准备升级了。真正做升级那天把源库最后一段归档拷过来recover一次追平然后alter database open正常打开即可。4. DBUA 执行升级图形界面与静默模式的具体填法DBUA 是 Oracle 自带的图形化升级工具19C 里它承担的工作远比看上去多跑预检查、调catupgrd.sql、升级时区、编译对象、注册监听、收集字典统计信息全是它在后台驱动。官方那份升级检查清单Doc ID 2545064.1基本就是围绕它写的静默方式另有一份Doc ID 2548985.1。这条路的好处是每一步都有日志坏处是它不会替你做决定前面欠的账全在预检查那页暴露。4.1 启动 DBUA 前必须确认的四件事DBUA 从 19C 的 home 启动但操作的实例是 11g 的环境变量必须同时指向两个方向这一点最容易出错。启动前我固定核四件事第一实例状态。库要处于OPEN或MOUNT不能是 nomountDBUA 连不上就报错退出。第二环境变量。ORACLE_HOME指 19CORACLE_SID指源库PATH里优先找 19C 的 binORACLE_BASE指 19C 的 base。# 启动 DBUA 前的环境变量顺序不能反 export ORACLE_BASE/u01/app/oracle export ORACLE_HOME/u01/app/oracle/product/19.14.0/db_1 export ORACLE_SIDerp export PATH$ORACLE_HOME/bin:$PATH export LD_LIBRARY_PATH$ORACLE_HOME/lib:$LD_LIBRARY_PATH # 确认指向正确别把 11g 的 sqlplus 拿起来 which sqlplus echo $ORACLE_HOME第三监听。19C 的监听要么已经在跑要么让 DBUA 自己起一个。如果沿用 11g 的监听配置端口冲突、服务名注册错都会在升级最后一步暴露。第四备份。升级前必须有一份完整的 RMAN 全备加上 11g 那个 home 原样保留——回退全靠这两样其他都是虚的。4.2 图形界面七个页面的实际选择图形界面需要 X11 转发或者直接在控制台跑dbua回车就起来。页面看着多真正要动脑的只有几处。第一页选要升级的实例列表里出现多个 SID 时要看清是哪个选错就等着出事。第二页是预检查DBUA 会自动跑一遍警告分两类必须处理的会标红建议处理的标黄标红的必须先解决否则下一步走不下去。第三页问要不要同时升级时区文件默认选是——时区文件不跟着升后续打补丁和DBMS_DST相关功能都会出问题这个后面单独讲。第四页是并行度和日志路径并行度按 CPU 核数给别超过 16。第五页问是否启用 Oracle Enterprise Manager 和备份这两项在生产机上我一般都不勾升级时间会短不少。第六页是概要把前面所有选择列一遍逐行读一遍再点完成。最后一页是进度条走完会给出成功或失败的结论。图形化最容易忽略的是日志目录。DBUA 会在页面上显示日志路径一般落在$ORACLE_BASE/cfgtoollogs/dbua/下务必记下来。升级中途报错第一个要看的就是这里而不是界面上那句笼统的升级失败。4.3 静默模式一条 dbua 命令加一份日志没有图形环境或者要写进脚本时用静默模式。参数名以dbua -help的输出为准不同小版本略有差异常见的写法是这样# 静默升级密码用引号包住防止特殊字符被 shell 吃掉 $ORACLE_HOME/bin/dbua -silent \ -sid erp \ -oracleHome /u01/app/oracle/product/19.14.0/db_1 \ -sysDBAUserName sys \ -sysDBAPassword YourPwd#2022 \ -timezone upgradeTimezoneFile-sid指定源库实例-oracleHome是目标 home 的绝对路径-sysDBAUserName和-sysDBAPassword给的是源库的 sys 口令-timezone upgradeTimezoneFile表示同时升级时区文件。密码里带#、$、!这类字符必须用单引号包住否则会被 shell 解释成注释或者变量引用DBUA 连不上库时报的是密码错误实际是密码被截断了——这种问题排查起来相当玄学。静默模式没有交互界面进度只能看日志跑起来之后用tail -f盯住 DBUA 的日志文件看到Database upgrade has been completed successfully才算完成。整个升级时长取决于库的大小和组件数量几十 G 的库一般四十分钟到两小时大库可能更久。4.4 升级日志与警告的读法DBUA 的日志分三层看错层会白花时间。第一层是 DBUA 自己的日志在$ORACLE_BASE/cfgtoollogs/dbua/下记录每一步的调用和返回码第二层是catupgrd.sql的执行日志在$ORACLE_BASE/cfgtoollogs/catupgrd/下升级脚本内部的报错全在这里第三层是$ORACLE_HOME/rdbms/admin/下的各类.log比如upgrade.log、catupgrd*.log。# 升级跑完后按错误级别快速过一遍日志 grep -iE ORA-|error|failed $ORACLE_BASE/cfgtoollogs/dbua/erp/upgrade/*.log | head -50 ls -lt $ORACLE_BASE/cfgtoollogs/catupgrd/ | headORA-开头的错误要逐个看上下文有些是升级脚本的预期行为比如组件不存在时抛的 ORA-00942有些是真正的阻断项。我的判断标准是脚本最后有没有走到COMP_TIMESTAMP结束标记有就是跑完了过程中的 ORA- 大多是组件层面的可容忍报错没有结束标记就是中途断了得从断点处查。5. 升级避坑DBUA 中途翻车的五类现场与救法升级这件事成功的路径只有一条失败的姿势千奇百怪。下面这五类是我和身边同行实际撞过的写清楚现象、原因和救法遇到时能少绕两小时。5.1 预检查卡在 COMPATIBLE 参数现象DBUA 第二页预检查转了很久最后标红提示 COMPATIBLE 参数不满足要求点下一步被拦住。原因源库的compatible参数低于 11.2.019C 的升级脚本要求源库至少处于 11.2.0 兼容级别因为很多新特性依赖这个基线。11.2.0.4 的库如果是从更早版本一路升上来的这个参数常常还停在旧值没动过。救法在源库上确认当前值再决定要不要调。SQL show parameter compatible; SQL alter system set compatible11.2.0.4 scopespfile;改完必须重启实例生效然后重跑 preupgrade。要注意的是compatible只能往高调不能往低调调高之后 11g 里的某些降级特性就不能用了生产库上动这个参数前要和业务确认。另外升级完成后这个参数还要再调一次到 19.0.0但那一步不着急等业务验证通过再动。5.2 无效对象导致升级脚本中断现象DBUA 跑到一半退出日志里出现大量ORA-04063: package body has errors或者ORA-06508。原因源库里有非 VALID 状态的存储过程、包、视图升级脚本在重新编译这些对象时失败连带后续的组件升级也断了。11g 里长期不编译的对象、依赖了已删除表的视图都是重灾区。救法升级前在源库把所有无效对象捞出来处理干净。-- 升级前必做列出无效对象并重编译 select owner, object_type, object_name from dba_objects where status INVALID order by 1,2,3; ?/rdbms/admin/utlrp.sql如果utlrp.sql跑完还有剩余逐个看dba_errors里的具体错误。业务自建的包编译不过要么改代码要么先删掉别带着进 19C。升级后如果又出现无效对象再跑一次utlrp.sql正常会清干净。5.3 时区文件没升导致后续补丁失败现象升级当时一切正常过几个月打 RU 补丁时报时区版本不匹配或者DBMS_DST相关查询报错。原因DBUA 那页问是否升级时区文件时选了否或者选了是但没等它跑完。11.2.0.4 的时区版本一般是 11 或 1419.14 自带的是 32差距这么大应用层做时间运算迟早出问题。救法升级时那一步务必选是。如果已经漏了事后单独补。-- 检查当前时区版本 select version from v$timezone_file; -- 升级时区文件需要停机 exec DBMS_DST.BEGIN_PREPARE(32); -- 中间跑 DBMS_DST 的 prepare 流程检查受影响的行 exec DBMS_DST.END_PREPARE;时区升级涉及带TIMESTAMP WITH TIME ZONE列的表数据量大的库要提前评估窗口。这件事拖得越久越麻烦因为每来一次 RU时区版本可能又往前走一版。5.4 归档空间打满DBUA 卡在 92%现象进度条走到九十多不动日志里开始刷ORA-19809、ORA-00257归档空间不足。原因升级过程中大量 DDL 产生归档db_recovery_file_dest_size设得太保守或者/arch这个挂载点本身快满了。这是纯血泪经验升级前不查归档余量等于给自己埋雷。救法升级前把db_recovery_file_dest_size调到实际需要的两三倍并把/arch的可用空间核一遍。SQL show parameter db_recovery_file_dest_size; SQL alter system set db_recovery_file_dest_size500G scopeboth; -- 顺手清一下过期归档别在升级窗口里做 RMAN delete noprompt archivelog until time sysdate-2;如果升级过程中已经卡住先扩归档空间DBUA 一般会自己继续往下跑实在不动就重启 DBUA它会从断点继续但前提是前面那些步骤没有产生不一致状态。5.5 升级失败想回退11g 的 home 已经动过现象升级失败想退回 11g结果发现 11g 的 home 里被写过东西startup报参数或组件版本异常回不去了。原因升级过程中有人顺手在 11g home 里跑了脚本或者两个 home 共用了同一个dbs目录、同一个oratab导致文件被覆盖。救法升级前给 11g 的 home 做一份目录级快照或者完整拷贝oratab里把两个 home 的条目分开写清楚升级期间不动 11g 的$ORACLE_HOME/dbs。真正回退靠的是升级前那份 RMAN 全备不是靠现场修 home——修 home 这条路十次有九次修出别的问题。回退时的顺序是关掉 19C 实例用 11g 的二进制起实例restore那份全备把控制文件和数据文件一起回滚。6. 升级后验收一套判断是否真的跑通的检查清单升级跑完DBUA 报成功不等于能交给业务。我的习惯是照着下面这套清单从头过一遍全过了才允许切连接串。-- 1. 版本与状态 select banner_full from v$version; select name, open_mode, log_mode from v$database; -- 2. 组件必须全部 VALID select comp_id, version, status from dba_registry order by 1; -- 3. 无效对象数量 select count(*) from dba_objects where status INVALID; -- 4. 时区版本 select version from v$timezone_file; -- 5. 归档与监听 archive log list;判断标准是这样一张表检查项通过标准不通过时先看哪数据库版本19.14.0.0.220118$ORACLE_HOME是否指错组件状态全部 VALID 或 OPTION OFFcatupgrd日志里对应组件段无效对象接近 0dba_errors逐条看时区版本32DBMS_DST流程是否走完归档模式ARCHIVELOGlog_archive_dest参数监听注册服务名能连上lsnrctl status与service_names这套检查之外我还会做两件事。一是抽查业务挑三五张核心表用select count(*)和源库最后追平的时间点对行数再跑一两条典型查询看执行计划有没有异常膨胀——19C 的优化器行为和 11g 差别不小个别执行计划会变这是最容易被忽略的地方。二是看 AWR升级后跑一个小时对比升级前的 TOP 等待事件如果出现明显的新型等待比如大量library cache相关说明有 SQL 在新版本上退化得在切业务前处理掉。postupgrade_fixups.sql别忘了在升级后的库上跑一遍它会把 preupgrade 阶段记录的、需要升级后处理的事项一次性执行掉包括权限回收、参数调整这些收尾工作。从那以后我每次做升级都会在正式窗口前先用这套清单在副本环境完整演练一遍包括回退那一步也真跑一次——只在纸面上确认回退可行和真的把库退回去是两回事。希望帮到你。本文还有配套的精品资源点击获取