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

简介Oracle 11g 到 19C 数据库升级详尽指导手册以单机库通过 DBUA 完成版本跨越为主线面向具备一定运维能力的 DBA 与数据库工程师解决 11g 停止补丁更新后如何安全迁移到 19C 稳定版的现实问题。内容从环境评估讲起先梳理官方给出的直接升级与间接升级路线、主机操作系统版本要求再转到 RMAN 备份与异机恢复到目标库的准备环节随后按操作顺序说明 DBUA 图形界面与静默两种升级方式的细节、参数和配置调整并强调核查脚本输出日志与告警信息的关键节点。文中还附有参考 MOS 文档编号及多类异常处置方案便于在遇到报错时快速定位。整个资源包只含 1 个 PDF 文件约 3.18MB结构紧凑可按章节对照实操。目前已有 1360 人学习适合需要一份可照做的升级检查表与排错思路的运维人员。1. 停库窗口只有几个小时Oracle 11g 升 19C 这件事先把 DBUA 摸透停库窗口批下来只有几个小时运维手里的 Oracle 11g 却已经被官方停了补丁19C 又必须上这条路绕不开 DBUA。这份 Oracle 19C DBUA 升级运维指南的价值不在讲原理而在于把「备份恢复到升级环境 → DBUA 图形化拉起 → 日志与告警核对」这条链路拆到每条命令都能照着敲的程度。它适合已经能独立做 RMAN 备份恢复、手上管着 11.2.0.4 单机库、需要在可控窗口里把生产库推到 19C 的人。真正容易翻车的不是点下一步而是点下一步之前那堆参数和归档有没有对齐——这篇文章就按这个顺序往下走。2. 升级路线判定版本矩阵和主机平台先卡掉一半人动手装软件之前有两件事必须先确认否则后面所有操作都是白费功夫源库版本落在直升级区间还是必须中转以及现有主机能不能装得下 19C。这两条属于硬约束不是调参数能绕过去的判断错了就是整晚白干。2.1 直升级与间接升级先看源库落在哪一档Oracle 对 19C 的升级路径给得很明确只有少数版本能一步到位。常见直升级矩阵大致是这样源库版本目标版本是否直升级11.2.0.4 及以上19.x是12.1.0.219.x是12.2.0.119.x是18.119.x是11.2.0.1 / 11.2.0.2 / 11.2.0.319.x否先到 11.2.0.411.1.0.6 / 11.1.0.719.x否先到 11.2.0.410.2.0.2 ~ 10.2.0.519.x否先到 11.2.0.4 或 12.1.0.210.1.0.519.x否先到 11.2.0.4 或 12.1.0.29.2.0.8 及更早19.x否先到 11.2.0.412.1.0.119.x否先到 12.1.0.2 或 12.2.0.1这张表最常被忽略的是 11.2.0.1 到 11.2.0.3 这几个小版本。很多人一看「11gR2」就想直接上 DBUA结果 DBUA 连源库都识别不了或者预检阶段直接报版本不支持。碰到这种库正确顺序是先把 11.2.0.3 补到 11.2.0.4再考虑 19C。补丁本身也是个窗口别指望一个晚上把两级升级都干完。另外同版本内的小补丁PSU/RU不影响能否直升级但会影响预检脚本报出的已知问题列表。我一般会先把源库的opatch lspatches结果记录下来升级后跟目标库对比出问题时能快速判断是不是补丁层面带进来的。# 记录源库版本与补丁信息升级前后都跑一次留档 $ORACLE_HOME/OPatch/opatch lspatches /home/oracle/patch_before.txt sqlplus -S / as sysdba EOF set pages 200 lines 200 select banner_full from v$version; select version, status from dba_registry; select name, value from v$parameter where name in (compatible,db_name,db_unique_name); EOF这段脚本没什么技巧就是留个基线。v$version里能看到源库确切版本dba_registry里的组件状态是后面判断能不能直接升级的重要依据——如果里面有 INVALID 或者 LOADING 状态的组件DBUA 预检大概率会拦下来。compatible参数要特别看一眼11g 里它通常还写着11.2.0.4.0升级到 19C 之后这个参数需要单独评估不能跟着升级自动跳。2.2 操作系统门槛Linux 6 上的 11g 只能换主机19C 对主机的要求比 11g 高了一档最低是 Linux 7。如果现有 11g 跑在 Linux 6 上这台机器装不了 19C只能新开一台 Linux 7 的主机把库搬过去再升级。这个决定必须在做方案的时候定下来而不是等到安装介质解压时才发现 glibc 版本不够。这种情况下架构就变成两台机角色主机软件用途源库生产主机11.2.0.4保持在线提供备份与归档升级库新主机 Linux 711.2.0.4 19.14恢复源库、执行 DBUA关键点是新主机上要装两套软件一套 11.2.0.4 用来打开源库数据文件并作为 DBUA 的源库 home另一套 19C 作为升级目标 home。只装 19C 是没法做 DBUA 的因为源库必须是正常运行状态而 11g 的数据文件不能被 19C 的软件直接 open。# 两套 ORACLE_HOME 并存时的目录规划示例 /u01/app/oracle/product/11.2.0/dbhome_1 # 源库 home用于打开恢复后的 11g 库 /u01/app/oracle/product/19.14.0/dbhome_1 # 目标 homeDBUA 升级到这里 /oradata/DEMOSB/ # 数据文件落盘位置与生产路径区分 /arch/ # 归档与 FRA目录别偷懒塞到同一层尤其是ORACLE_BASE。两套 home 如果共用 basecfgtoollogs、diag、admin这些目录会互相覆盖出问题查日志时根本分不清是哪个 home 写的。我一般给两个 home 各自独立的 base用不同 db_unique_name 隔离。2.3 用 preupgrade 检查脚本把家底摸清软件装好之后正式升级之前还有一步跑预检。Oracle 提供的preupgrade.jar在 19C 的$ORACLE_HOME/rdbms/admin目录下拷到源库主机用源库自己的 JDK 执行。注意必须用 11g 的 JDK 跑不能用 19C 的否则连不上 11g 实例。# 从 19C home 拷贝预检包到源库主机 scp /u01/app/oracle/product/19.14.0/dbhome_1/rdbms/admin/preupgrade.jar \ oraclesource-host:/home/oracle/ # 在源库主机执行TEXT 模式直接在终端输出 export ORACLE_HOME/u01/app/oracle/product/11.2.0/dbhome_1 export ORACLE_SIDDEMO $ORACLE_HOME/jdk/bin/java -jar /home/oracle/preupgrade.jar TEXT TERMINALTEXT TERMINAL表示结果直接打到屏幕适合第一次摸底。如果要把结果和修复脚本落盘换成FILE模式会在当前目录生成preupgrade.log、preupgrade_fixups.sql、postupgrade_fixups.sql三个文件。preupgrade_fixups.sql里是升级前必须处理的项比如失效对象、不支持的组件、字符集问题postupgrade_fixups.sql是升级后补做的动作。这两份脚本建议一条条看不要连上去就一把梭——里面有些语句是会改数据的。预检日志里最该盯的是三类组件兼容性dba_registry里如果有 Oracle Streams、旧版 OWB 这类 19C 已不支持的组件必须提前删掉或者迁移DBUA 不会帮你处理。无效对象dba_objects里 status 为 INVALID 的对象数量如果集中在某几个业务 schema先utlrp.sql编一遍把真正的问题暴露出来。参数与字符集compatible、sec_case_sensitive_logon、nls_characterset这几项预检会明确告诉你升级后会不会出问题。这一步花的时间通常比预期长尤其是字典表多的库跑十几分钟很正常。别嫌慢它报出的一条告警后面可能就是两小时的排查。3. 把生产库搬到升级环境RMAN 恢复到指定时间点升级环境准备好之后接下来这一步是把生产库的数据搬过去。这里有个取舍把源库保留在原处通过 RMAN 全备 归档恢复到新主机上的升级库生产库不动。好处是升级过程再怎么翻车生产库还在是最直接的后悔药代价是要多一份同等的存储和一段恢复时间。3.1 还原参数文件让目标库先认出自己恢复的第一步是拿回 spfile。源库导出时如果没带 spfile也可以用 pfile 手工拼但从备份集里 restore 出来最省事。# 在目标主机的 11g home 下操作 export ORACLE_HOME/u01/app/oracle/product/11.2.0/dbhome_1 export ORACLE_SIDDEMO export PATH$ORACLE_HOME/bin:$PATH rman target / RMAN startup nomount; RMAN restore spfile from /hisbak/spfile_DEMO_20220830_40444.ora; RMAN exit # 由 spfile 生成可编辑的 pfile便于改路径 sqlplus / as sysdba SQL create pfile/home/oracle/pfile.ora from spfile; SQL exitrestore spfile只把参数文件捞回来此时实例还没真正起来所以是startup nomount。生成 pfile 的目的是改路径——源库的control_files、audit_file_dest、db_recovery_file_dest这些参数指向的是生产主机的目录原样拿来用必然报错。# /home/oracle/pfile.ora 需要修改的关键行其余保持源库原值 *.audit_file_dest/u01/app/oracle/admin/demosb/adump *.audit_trailNONE *.compatible11.2.0.4.0 *.control_files/oradata/DEMOSB/controlfile/control01.dbf *.db_nameDEMO *.db_unique_nameDEMOSB *.db_recovery_file_dest/arch *.db_recovery_file_dest_size200G *.diagnostic_dest/u01/app/oracle *.log_archive_dest_1LOCATIONuse_db_recovery_file_dest VALID_FOR(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAMEDEMOSB *.memory_max_target128849018880 *.memory_target128849018880 *.processes6000 *.sga_max_size68719476736 *.sga_target68719476736 *.undo_tablespaceUNDOTBS1逐项说一下为什么要动db_name必须和源库完全一致DBUA 靠它认库db_unique_name改成带 SBstandby/standby backup 的意思的后缀避免和生产的 Data Guard 配置或者监听注册冲突。control_files指向本地新路径audit_file_dest、diagnostic_dest同理这三个参数不改实例起来就报 ORA-00205 或者写不进去。db_recovery_file_dest_size按恢复所需的归档量估算如果归档量大这个值要给够否则 recover 中途会因为 FRA 满而中断。memory_target这类内存参数升级环境如果内存比生产小要等比压下来不然实例起不来。19C 里 MEMORY_TARGET 的用法没变但升级后建议评估是否切到 SGA_TARGET PGA_AGGREGATE_TARGET 的手动管理方式自动内存管理在大内存机器上容易抖。改完 pfile 之后重建 spfile再startup nomountsqlplus / as sysdba SQL startup nomount pfile/home/oracle/pfile.ora; SQL create spfile/u01/app/oracle/product/11.2.0/dbhome_1/dbs/spfileDEMO.ora \ from pfile/home/oracle/pfile.ora; SQL shutdown abort; SQL startup nomount;顺序不能反必须先nomount起实例才能创建 spfile。建完之后重新以 spfile 启动确认参数生效。3.2 恢复控制文件与 catalog 加载备份参数文件就位后恢复控制文件。控制文件里记录了数据文件、归档的元信息有了它才能知道备份集里有什么。rman target / RMAN restore controlfile from /hisbak/DEMO_CONT_20220830_40443.ctl; RMAN sql alter database mount; RMAN catalog start with /hisbak/;restore controlfile会按 pfile 里control_files的路径落盘输出里能看到output file name/oradata/DEMOSB/controlfile/control01.dbf这一步成功就说明控制文件路径配置对了。catalog start with /hisbak/是把备份目录下的所有备份片注册进控制文件。如果备份目录文件很多这条命令会扫一阵属正常。执行完后用list backup确认能看到全备和归档备份集。有个细节catalog之后控制文件里的数据文件名还是生产环境的路径比如 ASM 里的DATA/...这就是为什么下面 restore 要用SET NEWNAME。RMAN report schema;report schema会列出控制文件里记录的所有数据文件和临时文件。如果此时出现RMAN-06139: WARNING: control file is not current for REPORT SCHEMA说明控制文件信息落后于备份集属于正常提示不影响后续恢复不用管它。3.3 restore 到指定时间点recover 追归档真正搬数据的是restore database。这里用SET NEWNAME把生产路径重定向到本地用SET UNTIL TIME指定恢复到哪个时间点。rman target / 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/DEMOSB/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; }参数说明SET NEWNAME FOR DATABASE TO .../%b%b是数据文件的原始文件名这样不同表空间的文件会落到同一个目录下且不重名。如果表空间多、单目录压力大可以按表空间分别SET NEWNAME FOR TABLESPACE。SET UNTIL TIME这是恢复上限。时间点选在备份集覆盖范围内即可因为后续还能追归档。双引号包住TO_DATE是为了让 RMAN 原样传给内核不加引号会被 RMAN 解析器吃掉。通道数4 个通道对应 4 个并行流具体开多少个看主机 CPU 和磁盘 IO。开太多反而互相抢 IO我一般按 CPU 核数的一半起步。restore 完成后先做一次switch database to copy把控制文件里的数据文件名切到新路径然后再开始 recoverrman target / RMAN 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 C1; RELEASE CHANNEL C2; RELEASE CHANNEL C3; RELEASE CHANNEL C4; }switch database to copy这一步经常被漏掉漏掉的话 recover 会去找原始路径的数据文件直接报找不到文件。switch 之后report schema里看到的路径就都是本地路径了。recover 的时间点可以分批往前推先恢复到 02:00再恢复到 07:00最后到 12:00。每推一次之前需要把源库新产生的归档拷过来并catalog一次。这种做法适合归档还在陆续产生、升级窗口又长的场景。3.4 read only 打开验证再继续追归档数据追到某个时间点后别急着做升级。先用 read only 方式打开让业务或者开发确认数据对不对sqlplus / as sysdba SQL alter database open read only;read only 打开状态下可以查数据、跑校验 SQL但不能写所以不会破坏恢复链。验证完之后如果要继续追归档必须先关掉sqlplus / as sysdba SQL shutdown abort; SQL startup mount; rman target / 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 C1; RELEASE CHANNEL C2; RELEASE CHANNEL C3; RELEASE CHANNEL C4; }不写SET UNTIL TIME的RECOVER DATABASE会一直追到归档的最后一个 SCN。追不动的时候会报RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 25197 and starting SCN of 18157927920这个报错不是故障意思是「归档只到这儿了」。想再往前推就得去源库把对应 sequence 的归档拷过来catalog之后重新RECOVER DATABASE。用list backup of archivelog from time sysdate-1能看到最近归档备份里包含的 sequence 范围对着报错里的 25197 找缺哪一段就行。到这里一个和源库同名、数据一致、能正常打开的 11g 库就在新主机上跑起来了。接下来才是 DBUA 真正干活的阶段。4. DBUA 升级实操从源库 OPEN 到 19C 起库DBUA 全称 Database Upgrade Assistant本质上是个带图形界面的包装器底层调的还是catupgrd.sql那一套。它的好处是把预检、备份、升级、编译、起库串成一条流水线中间某步失败会停下来告诉你日志在哪坏处是界面选项多选错一个后面补救很麻烦。4.1 升级前必须清掉的组件与参数进入 DBUA 之前源库要处于 OPEN 状态且满足几个前提。这一步做不干净DBUA 预检页面会红一片。-- 1. 确认组件状态重点看 19C 不支持的组件 select comp_id, comp_name, version, status from dba_registry order by comp_id; -- 2. 编译无效对象 ?/rdbms/admin/utlrp.sql -- 3. 确认时区文件版本 select * from v$timezone_file; -- 4. 检查字符集 select parameter, value from nls_database_parameters where parameter in (NLS_CHARACTERSET,NLS_NCHAR_CHARACTERSET); -- 5. 检查是否存在只读表空间 select tablespace_name, status from dba_tablespaces where status ONLINE;逐条说组件这块19C 已经不再支持 Oracle Streams、旧版 Oracle Warehouse Builder、Oracle Rules Manager 等。如果dba_registry里有必须在 11g 侧先用dbms_streams_adm.remove_streams_configuration之类的脚本卸掉不然 DBUA 会直接拒绝升级。APEX 这种如果版本太老也要先升到 19C 支持的版本否则升级后 APEX 起不来。utlrp.sql编译无效对象跑完再看dba_objects里 INVALID 的数量。如果还有大量 INVALID说明是业务对象本身有问题不是编译没跑完得让开发先修。时区文件版本不一致时DBUA 会问你要不要升级时区文件。这一步视数据字典规模而定字典表大的库可能要跑很久。提前知道耗时才能在窗口里安排。只读表空间、离线表空间在升级过程中可能引发ORA-01539之类的错误能改成读写就改改不了的记录下来升级时留意。参数方面有几个要提前定参数11g 常见值19C 建议说明compatible11.2.0.4.0升级后再改 19.0.0升级过程中保持原值升级完成后单独评估sec_case_sensitive_logonFALSE参数已废弃19C 密码默认大小写敏感应用账号密码要重新确认processes按需不低于 30019C 后台进程更多太小起不来sga_target按主机按主机升级期间建议固定大小不用自动内存管理sec_case_sensitive_logon这个参数在 19C 已经被废弃11g 时很多人设成 FALSE 图方便。升级后它不再生效如果应用连接串里的密码是全小写而库里存的是大写登录就会失败。升级前把关键账号的密码用alter user ... identified by重置一遍是省事的做法。4.2 启动 DBUA 并做出关键选项DBUA 在两套软件都装好的主机上启动。启动前确认环境变量指向 19C 的 home源库实例处于 OPEN 状态且在监听里注册。export ORACLE_HOME/u01/app/oracle/product/19.14.0/dbhome_1 export ORACLE_BASE/u01/app/oracle export PATH$ORACLE_HOME/bin:$PATH # 确认源库已被识别 lsnrctl status | grep DEMO ps -ef | grep pmon # 启动图形界面需要 DISPLAY $ORACLE_HOME/bin/dbuaDBUA 第一屏会让你选要升级的数据库。它能列出来的前提是源库实例正在运行且oratab或者监听注册信息里能找到它。如果列表是空的多半是环境变量串了 home或者 11g 的oratab条目被注释掉了。后面几屏的关键选项升级类型选「升级现有数据库」不是「创建新库」。并行度默认值通常够用。数据字典大的库可以适当调高但别拉满CPU 抢起来反而慢。时区文件如果检测到版本不一致勾选升级。备份DBUA 自带一个用 RMAN 做备份的选项。如果前面已经做过全备这里可以不勾省时间如果没做过强烈建议勾上它会在升级前自动打一个备份是最后一道保险。EM Express19C 里叫 Database Express端口默认 5500如果主机上已经有服务占用改一个。归档模式如果源库是归档模式保持归档升级过程中会产生大量 redo归档目录空间要给够。点击「Finish」之后就是等待。屏幕上会滚动显示当前执行的阶段预检、备份、升级数据字典、编译、起库。整个过程中不要去点取消也不要手工在另一个窗口操作数据库。真要中断等它自己报错停下来。4.3 静默模式与日志核对图形界面在跳板机或者无 X11 的环境里起不来这时候用静默模式。静默模式的参数不少最稳的做法是先跑dbua -help看当前版本的参数列表再照抄。# 静默升级示例参数以 dbua -help 输出为准 $ORACLE_HOME/bin/dbua -silent \ -sid DEMO \ -oracleHome /u01/app/oracle/product/19.14.0/dbhome_1 \ -diagnosticDest /u01/app/oracle/cfgtoollogs \ -timezoneUpgrade true \ -rmanBackup false-sid指定源库实例名-oracleHome是目标 19C home-diagnosticDest决定日志落点-timezoneUpgrade控制是否升级时区文件-rmanBackup控制升级前是否自动备份。静默模式跑起来没有交互所有判断都靠参数所以第一次用一定要在测试库上先跑一遍把参数组合确认下来再上生产。不管图形还是静默日志位置是固定的# DBUA 主日志目录按库名分 ls -l /u01/app/oracle/cfgtoollogs/dbua/DEMO/ # 升级过程中最关键的几个 # upgrade/upgrade1.log 预检与升级主流程 # upgrade/catupgrd*.log 字典升级脚本输出 # postchecks/postupgrade*.log 升级后检查看日志的顺序是先看主日志末尾有没有ORA-开头的错误再去看catupgrd的日志确认字典脚本是否跑完。DBUA 成功结束时最后一行通常是类似「Database upgrade has been completed successfully」的提示同时会列出几个 warning。这些 warning 不要直接忽略比如「Oracle Text 组件需要重新编译」「部分对象处于 INVALID 状态」都是升级后要补做的动作。5. 常见问题排查升级窗口里最容易翻车的四个点升级这件事流程本身不复杂复杂的是每一步的失败信息都很含糊。下面这几条是照着这套流程走下来最容易撞上的按「现象 → 原因 → 解决」写清楚遇到的时候可以直接对号入座。5.1 RMAN-06054 归档断档recover 卡在某个 SCN现象RECOVER DATABASE跑到一半停下来报RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 25197 and starting SCN of 18157927920然后就不动了。原因目标库的归档只拷到了某个 sequence源库还在继续产生新的归档中间断了一段。RMAN 不知道下一段归档在哪只能报「请求未知归档」。这不是数据库坏了是恢复链断了。解决回源库确认缺的是哪个 sequence把对应的归档文件拷过来重新catalog start with再跑一次不带SET UNTIL TIME的RECOVER DATABASE。如果不确定缺哪段用list backup of archivelog from time sysdate-1看目标库已有的 sequence 范围和源库v$archived_log对比差值就是缺的。# 目标库上看已有归档的 sequence 范围 rman target / RMAN list backup of archivelog from time sysdate-1; # 源库上看已产生的归档 sqlplus / as sysdba SQL select thread#, sequence#, first_time, next_time from v$archived_log where first_time sysdate - 1 order by thread#, sequence#;补归档的时候注意源库可能已经删了旧归档。如果归档被删且没有备份就只能恢复到现有归档的最后 SCN把时间点定在那里剩下的差异靠业务补数据。这也是为什么升级前要把归档备份保留住别让备份策略在窗口期把归档清掉。5.2 环境变量串了 home用 19C 打开了 11g 的数据文件现象startup mount时报错提示控制文件或数据文件版本与 ORACLE 版本不兼容类似ORA-00201: control file version 19.0.0.0.0 incompatible with ORACLE version 11.2.0.0.0或者反过来。库根本起不来。原因恢复阶段必须用 11.2.0.4 的 home 和 11g 的 RMAN。如果ORACLE_HOME、PATH、ORACLE_SID指向了 19C或者which rman查到的是 19C 的 rman就会出现版本错配。数据文件头是 11g 写的19C 的软件在升级前不认它。解决每次开新窗口先确认三个变量别嫌烦。echo $ORACLE_HOME echo $ORACLE_SID which rman which sqlplus输出里ORACLE_HOME必须是/u01/app/oracle/product/11.2.0/dbhome_1rman和sqlplus的路径也要在同一 home 下。这一步看起来是基础操作但窗口一多、切来切去串 home 是最常见的翻车方式。我一般会写两个小脚本env11.sh和env19.shsource一下切换避免手工 export 出错。5.3 表空间空间不足catupgrd 中途中断现象DBUA 跑到「Upgrading Data Dictionary」阶段失败日志里能看到ORA-01653: unable to extend table ... by ... in tablespace SYSAUX或者ORA-30036: unable to extend segment by 8 in undo tablespace。原因升级过程中要往 SYSAUX 里写大量字典数据还要跑大量 DDLUNDO 消耗也很大。11g 时期给 SYSAUX 留的空间到了 19C 的升级过程里经常不够。UNDO 表空间如果设了自动扩展但上限太小也会卡住。解决升级前先把这两个表空间扩到位别等报错再补。-- 查看当前使用率与自动扩展配置 select tablespace_name, bytes/1024/1024 mb, maxbytes/1024/1024 max_mb, autoextensible from dba_data_files where tablespace_name in (SYSAUX,UNDOTBS1); -- 扩容示例 alter database datafile /oradata/DEMOSB/datafile/sysaux01.dbf resize 8G; alter database datafile /oradata/DEMOSB/datafile/sysaux01.dbf autoextend on next 512M maxsize 32G; alter database datafile /oradata/DEMOSB/datafile/undotbs01.dbf resize 16G;扩完不用重启直接重跑 DBUA 即可。如果中断发生在字典升级阶段重跑之前确认源库状态——DBUA 中断后源库可能处于部分升级状态这时候直接重跑有可能出问题。稳妥的做法是从 3.3 步的 restore 重来一遍反正备份和归档都在代价就是时间。5.4 时区文件升级卡很久密码策略又踩一脚现象DBUA 界面停在「Updating time zone file」十几分钟不动进度条几乎不走升级完成后应用连上来报密码错误或者报ORA-28040: No matching authentication protocol。原因时区文件升级要遍历数据字典里带 TIMESTAMP WITH TIME ZONE 类型的表字典量大时耗时很长属于正常现象不是卡死。密码问题则是 19C 默认密码大小写敏感加上客户端版本太老认证协议对不上。解决时区文件这步就是等提前在窗口里预留 20 到 40 分钟。如果实在想缩短可以在升级前先手工收集字典统计信息让优化器有正确的执行计划间接减少耗时。密码和客户端问题分两头处理服务端把关键账号的密码重置一遍确认dba_users里password_versions包含 11G 和 12C 及以上的版本客户端那边11g 时代的 JDBC 驱动连 19C 会报 ORA-28040需要把驱动升到支持 19C 的版本或者在服务端sqlnet.ora里临时放开认证版本但这只是过渡手段长期还是要换驱动。6. 升级完成之后验证清单和那条不能越的线DBUA 提示成功不等于升级真的成功。屏幕上那些 warning 得一条条看完然后按下面的顺序做验证检查项命令期望结果组件状态select comp_id,status from dba_registry;全部 VALID无效对象select count(*) from dba_objects where statusINVALID;数量可控且无业务对象版本信息select banner_full from v$version;19.14.0.0升级历史select action_time, action, namespace, version from registry$history;有 UPGRADE 记录时区版本select version from v$timezone_file;与 19C 一致字典统计exec dbms_stats.gather_dictionary_stats;执行成功无效对象如果集中在某几个业务 schema先跑utlrp.sql再统计一次还是大量 INVALID 的话基本可以判断是业务对象本身依赖了已废弃的特性得让开发介入。dbms_stats.gather_dictionary_stats这步别省升级后优化器没有字典统计执行计划会乱飘这个玄学问题排查起来很痛苦。还有一条不能越的线19C 的库一旦open过就回不到 11g 了。19C 读过的数据文件11g 的软件打不开。所以升级前的全备是唯一的后悔药备份不验证等于没有备份——做一次restore validate database确认备份集完整可用。rman target / RMAN restore validate database; RMAN list backup of database summary;从那以后我每次做升级都会在 DBUA 点下去之前把这两条命令跑一遍然后立刻给升级后的 19C 库打一个标为 baseline 的全备。升级前留回退的备份升级后留干净的起点这两份备份是窗口里唯一能救命的东西。希望帮到你。本文还有配套的精品资源点击获取