简介面向具备一定运维基础的数据库管理员这份 Oracle 11g 升级至 19C 的运维指导手册以 DBUA 工具为主线解决旧版本停止补丁更新后如何平稳迁移到长期支持版本的实际问题。内容先讲清升级路线判断与操作系统版本要求再走通生产库通过 RMAN 备份恢复到目标库、参数文件重建、归档追平等准备环节随后给出 DBUA 图形化与静默两种升级方式的完整流程并附 MOS 文档编号便于溯源文中强调每一步的顺序与命令细节配合日志与警告核对方法、常见故障处理方案可帮助读者在正式切换前发现隐患、预留回退余地也可用于评估升级可行性。压缩包仅含 1 个 PDF 文件约 3.18MB以图文步骤与命令清单为主单文件结构便于按章节顺序对照执行。已有 1360 人学习下载适合正在做版本替换或准备执行升级的运维人员参考。1. 11g 升 19C 卡在 DBUA 预检查那几条红色告警到底要不要动上周又有人在群里丢了一张 DBUA 截图满屏红色最上面一行是PRVG-1101 : Failed to execute the command底下还跟着ORA-32004、ORA-00845。发图的人问得特别实在这些到底是必须处理的还是可以直接点 Next 的Oracle 11g 到 19C 的升级报错其实很集中预检查过不去、恢复卡在归档序列、DBUA 跑一半无响应、升级后组件状态INVALID。它们几乎都跟准备阶段的一两个参数有关系。这份 Oracle 19C DBUA 升级指导手册把 11.2.0.4 单机升 19.14 的全流程、备份恢复细节、追归档失败的处理记录和 MOS 文档编号都摊在明面上。这篇就按报错顺序把踩坑点一个个拆开讲适合正在做数据库升级运维、被 DBUA 卡住的 DBA 对照排查。2. 预检查过不去ORA-00845 与 PRVG-1101 的真实成因DBUA 最劝退的地方在于它把一堆互不相干的问题堆在你面前让你误以为要一次性全解决。实际上这些告警有明确的优先级先修内存参数和操作系统前置条件再谈升级路径与兼容性参数顺序搞反了改完重启实例又会冒出新的报错。2.1 ORA-00845MEMORY_TARGET 与 /dev/shm 的老账ORA-00845: MEMORY_TARGET not supported on this system是 11g 上极高频的一条根源不在 Oracle 参数本身而在操作系统的/dev/shm容量。11.2.0.4 默认使用 AMMmemory_target要与/dev/shm对齐很多生产库的memory_max_target设为 128G而主机/dev/shm只有物理内存的一半实例启动就直接失败。# 先看当前 shm 大小和 mounted 参数 df -h /dev/shm # 临时扩大重启失效仅用于验证 mount -o remount,size64G /dev/shm # 永久生效写入 /etc/fstab注意 size 按物理内存 60%~80% 取 tmpfs /dev/shm tmpfs defaults,size64G 0 0参数size必须大于memory_max_target否则startup时依然报 ORA-00845。如果你的库内存给到了 128G而物理内存只有 256G那/dev/shm设 90G 左右是常见做法。改完用sqlplus / as sysdba起库验证一次确认show parameter memory_target的数值与 shm 匹配。还有一个容易忽略的点升级到 19C 之后官方更推荐 AMM 关闭、走 ASMMsga_targetpga_aggregate_target。如果源库用的是memory_target在 DBUA 预检查阶段就会被提示。我一般的做法是升级前先把参数拆开写进 pfile减少 DBUA 中途因内存参数重算失败的概率。2.2 PRVG-1101别急着重装先看执行用户与权限PRVG-1101 : Failed to execute the command这条的迷惑性在于它什么都不告诉你。它来自集群验证工具CVUDBUA 调用cluvfy检查主机时就报出来了。常见的三个成因一是执行 DBUA 的用户不是oracle而是 root 或别的账号导致cluvfy无法读取/etc/oratab和$ORACLE_HOME。二是$ORACLE_HOME/bin下部分二进制丢了执行权限常见于从其他机器拷贝安装目录的场景。三是TMPDIR指向的目录空间不足或不可写。# 用 oracle 用户执行先手工跑一次 CVU报错信息比 DBUA 界面清楚得多 su - oracle export TMPDIR/tmp $ORACLE_HOME/bin/cluvfy stage -pre dbinst -n $(hostname) -verbose # 检查关键二进制权限 ls -l $ORACLE_HOME/bin/oracle $ORACLE_HOME/bin/sqlplus # 期望 -rwsr-s--x若丢了 s 位 chmod 6751 $ORACLE_HOME/bin/oraclecluvfy手工跑出来的日志在$ORACLE_HOME/cv/log或者$ORACLE_BASE/oraInventory/logs下界面里那句干巴巴的 PRVG-1101 在日志里往往跟着一条具体的“cannot access”或“permission denied”。定位到具体文件再修别一上来就重装软件那是最费时间的一条路。提示预检查阶段的告警分「阻塞」和「警告」两类。CVU 的检查结果里带failed的必须处理warning可以先记录后放行但升级完成后要回头确认对应项尤其是字符集和时区版本。2.3 升级路线没选对11.2.0.1 直接点 Next 必然失败DBUA 不会阻止你选一条不通的路线它只在升级到一半时告诉你目标版本不兼容。按官方支持矩阵能直连 19C 的源库只有 11.2.0.4 及以上、12.1.0.2、12.2.0.1、18.1。11.2.0.1 到 11.2.0.3 必须先进到 11.2.0.410.2 系列则要经 11.2.0.4 或 12.1.0.2 中转。源库版本升级路径是否可直连 19C11.2.0.4直接升 19.x是11.2.0.1~11.2.0.3先升 11.2.0.4否10.2.0.2~10.2.0.5经 11.2.0.4 或 12.1.0.2否12.1.0.1先升 12.1.0.2 或 12.2.0.1否12.2.0.1、18.1直接升 19.x是先跑一句select version from v$instance;把源库版本钉死再对照这张表。低于 11.2.0.4 的库先把 11.2.0.4 补丁打齐补丁号 31537677 是 11.2.0.4.201020 这一档的常见组合再进 DBUA否则后面遇到的不是预检查告警而是升级途中直接中断。2.4 主机版本不够Linux 6 上的 19C 装不上19C 对操作系统的最低要求是 Linux 7。如果 11g 跑在 Linux 6 上升级方案就得调整为「新主机装 19C 数据迁移」DBUA 的原地升级路径走不通。此时流程变成在新主机上装好 19C 软件通过 RMAN 把源库备份恢复到新主机再用 DBUA 在原 ORACLE_HOME 内做版本转换。这也是源库和目标库部署在两个ORACLE_HOME时最容易混淆的地方——源库的ORACLE_HOME是/u02/app/oracle/product/11.2.0/db19C 的ORACLE_HOME是/u01/app/oracle/product/19.14.0/db_1环境变量里ORACLE_HOME指向哪个DBUA 就认哪个源库。切换用户后务必source .bash_profile并echo $ORACLE_HOME确认一遍这条血泪经验能省掉后面一半的排查时间。3. 恢复阶段报错RMAN-06054 与归档追不上的处理升级前先把生产库的备份恢复到目标库并保持在 MOUNT 状态是保留回退能力的标准动作。这一步的报错比 DBUA 本身更致命因为它决定你有没有一个可用的源库副本。3.1 RMAN-06054media recovery requesting unknown archived logRMAN-03002: failure of recover command at 08/31/2022 21:40:31 RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 25197 and starting SCN of 18157927920这条报错的意思是控制文件记录的最新 SCN 之后还缺一个归档RMAN 想继续推但找不到。原因有三类备份集里归档不全、db_recovery_file_dest空间满导致归档被自动清理、或者控制文件是从旧备份恢复的里面记录的归档位置跟实际不符。# 先看备份集里到底有哪些归档看序列号断在哪 rman target / RMAN list backup of archivelog from time sysdate-1; # 把新拷过来的归档重新注册进控制文件 RMAN catalog start with /hisbak/; # 再确认一遍缺失序列 RMAN list archivelog all;排查顺序是「先 catalog再 list最后 recover」。很多情况下归档文件已经在/hisbak目录里了只是控制文件不知道catalog start with一跑就能续上。如果list backup of archivelog显示序列号中间有断档那就是备份环节漏了只能从源库补拷。3.2 追归档到某个时间点UNTIL TIME 的写法与坑手册里这段做得很细先restore database到2022-08-30:02:00:00再recover到07:00:00再往前推到12:00:00每推一次都重新startup mount。这个分步推进的思路是对的尤其对归档量大、需要边拷边恢复的场景。run { ALLOCATE CHANNEL C1 DEVICE TYPE DISK; ALLOCATE CHANNEL C2 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 C2; RELEASE CHANNEL C1; }%b是数据文件基名SET NEWNAME配合SWITCH DATABASE TO COPY可以把数据文件落到新路径避免源库文件系统路径在目标主机上不存在导致的ORA-19504。UNTIL TIME用的是数据库时区下的时间跟操作系统时区不一致时要特别小心差 8 小时是常见翻车点建议先用SELECT SYSDATE FROM DUAL;核一下库时间再写。已open read only的库要继续追归档必须先shutdown abort再startup mount不能直接 recover。手册里专门标了这一步很多人省掉它然后卡在ORA-01113: file 1 needs media recovery上。3.3 归档缺失的最后手段增量备份配合归档实在凑不齐时还有一条路从源库拿一份新的 incremental backup在目标库上做增量恢复把差距补上。前提是源库的 SCN 起点与目标库当前 SCN 能衔接。# 源库侧基于当前 SCN 做增量 RMAN backup incremental from scn 18157927920 database format /hisbak/incr_%U; # 目标库侧catalog 后应用 RMAN catalog start with /hisbak/; RMAN recover database noredo;recover database noredo只应用增量备份、不读归档适合作最后一次对齐。这个方式对归档保留策略不友好的老库尤其有用代价是要对源库再跑一次备份窗口得提前申请。3.4 恢复期间的三个参数绝不是摆设手册恢复参数文件那一节给了一串参数其中几个直接决定恢复成败参数值作用db_unique_namebsoftsb与源库区分避免 Data Guard 或路径冲突db_file_name_convert隐含在 NEWNAME 中源目标路径不一致时重定向文件db_recovery_file_dest_size200G空间不足会导致归档写入失败恢复中断control_file_record_keep_time15太小会让控制文件过早丢弃归档记录sec_case_sensitive_logonFALSE11g 默认升级到 19C 后密码策略会变更db_recovery_file_dest_size设小了是恢复阶段的高频故障表现是归档写着写着报ORA-19809。空间充足时给到 200G 是手册里的实际取值生产上按归档生成速率乘保留天数算更稳妥。注意恢复参数文件后要先create pfile from spfile改 port、路径、audit 目录之后再反向生成 spfile。直接改 spfile 二进制风险高而且出问题时没有任何可读的备份。4. DBUA 执行阶段失败ORA-32004 与组件无效的收尾预检查全绿、源库副本也就位了DBUA 真正跑起来之后仍然有坑。这一阶段报错的特点是「看着像失败其实是警告」和「看着像成功其实组件没编译过」。4.1 ORA-32004过时参数导致的启动失败ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance这条在 11g 升 19C 时几乎必现它不是一个错误而是提示你 pfile/spfile 里有 19C 已经不认的参数比如sec_case_sensitive_logon、audit_trailNONE的部分取值、resource_manager_plan的旧写法。-- 升级前先扫一遍过时参数 SELECT name, value FROM v$parameter WHERE isdeprecated TRUE; -- 常见需要清理的 -- sec_case_sensitive_logon19C 中已不可动态改建议升级前显式设为 FALSE 并固化 -- audit_trailNONE19C 推荐改为 DB 或 NONE 明确写法 -- _system_trig_enabled 等隐藏参数的遗留设置处理方式不是简单地把告警忽略而是在升级前把过时参数从 pfile 里删掉重新生成 spfile再启动源库确认业务正常。带着一堆过时参数进 DBUA升级完成后实例可能起不来那时候再回滚成本就高了。4.2 组件状态 INVALIDDBUA 报成功之后才是硬仗DBUA 到最后一步显示升级成功很多人就此收工第二天业务报错才发现DBA_REGISTRY里有组件是INVALID。11g 里装过的Oracle Text、OLAP、Spatial、XDB这些组件在 19C 上需要重新编译。-- 升级后必须查这一张表 SELECT comp_id, comp_name, version, status FROM dba_registry ORDER BY comp_id; -- 对无效组件逐个执行 ?/rdbms/admin/utlrp.sql -- 如果组件本身 INVALID先重装再编译例如 Oracle Text -- ?/ctx/admin/catctx.sql 需要按文档步骤执行utlrp.sql跑完再看dba_registry仍为INVALID的组件要按组件名单独处理而不是反复跑utlrp。典型场景是XDB或Oracle Text在升级时没有正确装载需要先catnoom之类的脚本清理再重装。升级后的验证清单里dba_registry、dba_objects无效对象数、dba_jobs、dba_scheduler_jobs这四项缺一不可。-- 无效对象数量正常应该接近 0 SELECT COUNT(*) FROM dba_objects WHERE status INVALID; -- 时区版本19C 要求升级后跑 utltz_upg_check.sql 确认 SELECT version FROM v$timezone_file;时区文件版本是另一个隐蔽项。11g 的时区版本与 19C 不同DBUA 会提示需要升级时区数据utltz_upg_check.sql检查通过后再跑utltz_upg_apply.sql。这一步不做涉及TIMESTAMP WITH TIME ZONE的查询会出现时间偏移而且极难排查。4.3 DBUA 静默模式无人值守升级的参数写法图形界面在跳板机上经常卡住或者渲染错位DBUA 支持静默执行适合有自动化需求的运维场景。# 先在图形模式下走一遍记录配置再导出响应文件 $ORACLE_HOME/bin/dbua -silent \ -sid bsoft \ -oracleHome /u01/app/oracle/product/19.14.0/db_1 \ -sysDBAUserName sys \ -sysDBAPassword *** \ -replayFile /home/oracle/dbua_replay.rsp \ -log /home/oracle/dbua_silent.log-replayFile是图形模式导出的响应文件里面记录了目标版本、时区升级、组件选择等选项。静默模式失败时日志在-log指定路径下报错信息比界面完整。跑静默升级前一定要确认ORACLE_HOME环境变量指向 19C 的目录否则 DBUA 会拿错软件版本做检查。4.4 升级后性能回退优化器统计信息必须重收集升级完成、组件也正常业务上线后反馈慢查询变多这通常是优化器统计信息没更新导致的。11g 的统计信息在 19C 优化器下参考价值下降加上 19C 默认开启了自动 SQL 计划管理行为可能和 11g 不一致。-- 升级后收集字典与固定对象统计信息 EXEC DBMS_STATS.GATHER_DICTIONARY_STATS; EXEC DBMS_STATS.GATHER_FIXED_OBJECTS_STATS; -- 保留 11g 的统计信息以便对比回退 EXEC DBMS_STATS.CREATE_STAT_TABLE(SYS,STATS_11G_BAK);GATHER_DICTIONARY_STATS建议在业务低峰跑耗时不短但必须做。另外把 11g 的统计信息导出到备份表万一执行计划大面积变化可以用DBMS_STATS.IMPORT_TABLE_STATS回灌对比这是排计划突变最省事的办法。5. 避坑清单五条升级现场的常见问题5.1 DBUA 跑到一半无响应界面卡在「正在执行升级脚本」现象进度条停在某个百分比十几分钟不动日志文件也没有新内容。 原因多数是TMPDIR空间不足或者 DBUA 内部调用的catupgrd.sql被锁等待阻塞。目标库如果还有别的会话连着升级脚本拿不到排他锁。 解决开另一个窗口tail -f $ORACLE_BASE/cfgtoollogs/dbua/*/upgrade*.log看到具体卡在哪个脚本确认df -h /tmp剩余空间大于 2Gshutdown immediate掉所有其他会话后重跑。别直接 kill DBUA 进程否则dba_registry可能留下中间状态。5.2 源库是生产环境恢复时把生产文件覆盖了现象在目标机上执行SET NEWNAME时漏了SWITCH DATABASE TO COPY恢复完没切文件后续open报找不到数据文件。 原因RESTORE只是把文件写到新路径控制文件里记录的还是老路径不SWITCH不会生效。 解决在run块里RESTORE之后紧跟SWITCH DATABASE TO COPY或者恢复后单独执行一次。执行前用REPORT SCHEMA确认所有文件名都落在/oradata/BSOFTSB/datafile/下。5.3 open read only 之后直接 recover报需要介质恢复现象只读打开库想继续追归档直接recover database报ORA-01113。 原因只读打开的库处于非 MOUNT 状态RMAN 无法执行恢复。 解决shutdown abort→startup mount→ 再recover。这个顺序不能省手册里专门写了这一条是很多人跳过的一步。5.4 升级后应用连不上报 ORA-01017 密码无效现象升级前能连的账号升级后密码验证失败。 原因11g 的sec_case_sensitive_logonFALSE与 19C 的密码大小写策略不兼容加上sqlnet.ora里的SQLNET.ALLOWED_LOGON_VERSION默认值被提高。 解决在sqlnet.ora里把SQLNET.ALLOWED_LOGON_VERSION_SERVER临时调低到 8 兼容老客户端同时让应用侧确认密码大小写长期方案是重置密码并统一为大小写敏感。5.5 升级完成后忘记更新监听与 tnsnames现象库起来了应用连的却是老库地址或者lsnrctl status里服务名对不上。 原因目标库的service_names沿用了源库配置或者监听器注册的还是旧ORACLE_HOME的服务。 解决lsnrctl status确认实例注册到正确的ORACLE_HOMEalter system register;手动触发注册必要时lsnrctl reload。别只看ps -ef | grep pmon进程在但服务没注册是两回事。6. 如何快速定位这类升级故障我的排查顺序从报错到根因我固定的顺序是「先看日志再看视图最后比对参数」。日志优先级DBUA 自身的$ORACLE_BASE/cfgtoollogs/dbua/sid/下的upgrade*.log和postupgrade*.logCVU 的cluvfy日志RMAN 的sbtio.log或命令输出。三份日志覆盖预检查、恢复、执行三个阶段任何一条报错都能在其中一份里找到上下文。视图优先级dba_registry看组件状态v$instance看版本v$parameter配合isdeprecatedTRUE扫过时参数dba_objects看无效对象。四张表查完升级是否真正成功基本心里有数。参数比对把升级前的 pfile 和升级后的 spfile 生成文本diff一次重点关注内存、字符集、时区、审计、密码策略这五类。差异项逐条确认是 DBUA 自动改的还是遗留的。-- 一条语句把升级后的健康状态拉出来 SELECT (SELECT version FROM v$instance) AS db_version, (SELECT COUNT(*) FROM dba_objects WHERE status INVALID) AS invalid_objects, (SELECT COUNT(*) FROM dba_registry WHERE status VALID) AS bad_components, (SELECT version FROM v$timezone_file) AS tz_version FROM dual;结果对照invalid_objects为 0 或个位数bad_components为 0tz_version与 19C 要求一致才算真正升级完成。任何一项不符回到对应章节找处理脚本不要直接开业务。最后说个教训。我早期做升级时把 DBUA 显示「升级成功」当成终点结果第二天客户报时间字段差了几小时查了半天才发现时区文件没升级。从那以后我每次升级完都强制走一遍验证 SQLdba_registry、无效对象、时区版本、监听注册这四项不通过就不交付。这套习惯配合这份手册里的恢复和追归档流程能让你在真正出问题时手里有据可查、有路可退。希望帮到你。本文还有配套的精品资源点击获取
简介面向具备一定运维基础的数据库管理员这份 Oracle 11g 升级至 19C 的运维指导手册以 DBUA 工具为主线解决旧版本停止补丁更新后如何平稳迁移到长期支持版本的实际问题。内容先讲清升级路线判断与操作系统版本要求再走通生产库通过 RMAN 备份恢复到目标库、参数文件重建、归档追平等准备环节随后给出 DBUA 图形化与静默两种升级方式的完整流程并附 MOS 文档编号便于溯源文中强调每一步的顺序与命令细节配合日志与警告核对方法、常见故障处理方案可帮助读者在正式切换前发现隐患、预留回退余地也可用于评估升级可行性。压缩包仅含 1 个 PDF 文件约 3.18MB以图文步骤与命令清单为主单文件结构便于按章节顺序对照执行。已有 1360 人学习下载适合正在做版本替换或准备执行升级的运维人员参考。1. 11g 升 19C 卡在 DBUA 预检查那几条红色告警到底要不要动上周又有人在群里丢了一张 DBUA 截图满屏红色最上面一行是PRVG-1101 : Failed to execute the command底下还跟着ORA-32004、ORA-00845。发图的人问得特别实在这些到底是必须处理的还是可以直接点 Next 的Oracle 11g 到 19C 的升级报错其实很集中预检查过不去、恢复卡在归档序列、DBUA 跑一半无响应、升级后组件状态INVALID。它们几乎都跟准备阶段的一两个参数有关系。这份 Oracle 19C DBUA 升级指导手册把 11.2.0.4 单机升 19.14 的全流程、备份恢复细节、追归档失败的处理记录和 MOS 文档编号都摊在明面上。这篇就按报错顺序把踩坑点一个个拆开讲适合正在做数据库升级运维、被 DBUA 卡住的 DBA 对照排查。2. 预检查过不去ORA-00845 与 PRVG-1101 的真实成因DBUA 最劝退的地方在于它把一堆互不相干的问题堆在你面前让你误以为要一次性全解决。实际上这些告警有明确的优先级先修内存参数和操作系统前置条件再谈升级路径与兼容性参数顺序搞反了改完重启实例又会冒出新的报错。2.1 ORA-00845MEMORY_TARGET 与 /dev/shm 的老账ORA-00845: MEMORY_TARGET not supported on this system是 11g 上极高频的一条根源不在 Oracle 参数本身而在操作系统的/dev/shm容量。11.2.0.4 默认使用 AMMmemory_target要与/dev/shm对齐很多生产库的memory_max_target设为 128G而主机/dev/shm只有物理内存的一半实例启动就直接失败。# 先看当前 shm 大小和 mounted 参数 df -h /dev/shm # 临时扩大重启失效仅用于验证 mount -o remount,size64G /dev/shm # 永久生效写入 /etc/fstab注意 size 按物理内存 60%~80% 取 tmpfs /dev/shm tmpfs defaults,size64G 0 0参数size必须大于memory_max_target否则startup时依然报 ORA-00845。如果你的库内存给到了 128G而物理内存只有 256G那/dev/shm设 90G 左右是常见做法。改完用sqlplus / as sysdba起库验证一次确认show parameter memory_target的数值与 shm 匹配。还有一个容易忽略的点升级到 19C 之后官方更推荐 AMM 关闭、走 ASMMsga_targetpga_aggregate_target。如果源库用的是memory_target在 DBUA 预检查阶段就会被提示。我一般的做法是升级前先把参数拆开写进 pfile减少 DBUA 中途因内存参数重算失败的概率。2.2 PRVG-1101别急着重装先看执行用户与权限PRVG-1101 : Failed to execute the command这条的迷惑性在于它什么都不告诉你。它来自集群验证工具CVUDBUA 调用cluvfy检查主机时就报出来了。常见的三个成因一是执行 DBUA 的用户不是oracle而是 root 或别的账号导致cluvfy无法读取/etc/oratab和$ORACLE_HOME。二是$ORACLE_HOME/bin下部分二进制丢了执行权限常见于从其他机器拷贝安装目录的场景。三是TMPDIR指向的目录空间不足或不可写。# 用 oracle 用户执行先手工跑一次 CVU报错信息比 DBUA 界面清楚得多 su - oracle export TMPDIR/tmp $ORACLE_HOME/bin/cluvfy stage -pre dbinst -n $(hostname) -verbose # 检查关键二进制权限 ls -l $ORACLE_HOME/bin/oracle $ORACLE_HOME/bin/sqlplus # 期望 -rwsr-s--x若丢了 s 位 chmod 6751 $ORACLE_HOME/bin/oraclecluvfy手工跑出来的日志在$ORACLE_HOME/cv/log或者$ORACLE_BASE/oraInventory/logs下界面里那句干巴巴的 PRVG-1101 在日志里往往跟着一条具体的“cannot access”或“permission denied”。定位到具体文件再修别一上来就重装软件那是最费时间的一条路。提示预检查阶段的告警分「阻塞」和「警告」两类。CVU 的检查结果里带failed的必须处理warning可以先记录后放行但升级完成后要回头确认对应项尤其是字符集和时区版本。2.3 升级路线没选对11.2.0.1 直接点 Next 必然失败DBUA 不会阻止你选一条不通的路线它只在升级到一半时告诉你目标版本不兼容。按官方支持矩阵能直连 19C 的源库只有 11.2.0.4 及以上、12.1.0.2、12.2.0.1、18.1。11.2.0.1 到 11.2.0.3 必须先进到 11.2.0.410.2 系列则要经 11.2.0.4 或 12.1.0.2 中转。源库版本升级路径是否可直连 19C11.2.0.4直接升 19.x是11.2.0.1~11.2.0.3先升 11.2.0.4否10.2.0.2~10.2.0.5经 11.2.0.4 或 12.1.0.2否12.1.0.1先升 12.1.0.2 或 12.2.0.1否12.2.0.1、18.1直接升 19.x是先跑一句select version from v$instance;把源库版本钉死再对照这张表。低于 11.2.0.4 的库先把 11.2.0.4 补丁打齐补丁号 31537677 是 11.2.0.4.201020 这一档的常见组合再进 DBUA否则后面遇到的不是预检查告警而是升级途中直接中断。2.4 主机版本不够Linux 6 上的 19C 装不上19C 对操作系统的最低要求是 Linux 7。如果 11g 跑在 Linux 6 上升级方案就得调整为「新主机装 19C 数据迁移」DBUA 的原地升级路径走不通。此时流程变成在新主机上装好 19C 软件通过 RMAN 把源库备份恢复到新主机再用 DBUA 在原 ORACLE_HOME 内做版本转换。这也是源库和目标库部署在两个ORACLE_HOME时最容易混淆的地方——源库的ORACLE_HOME是/u02/app/oracle/product/11.2.0/db19C 的ORACLE_HOME是/u01/app/oracle/product/19.14.0/db_1环境变量里ORACLE_HOME指向哪个DBUA 就认哪个源库。切换用户后务必source .bash_profile并echo $ORACLE_HOME确认一遍这条血泪经验能省掉后面一半的排查时间。3. 恢复阶段报错RMAN-06054 与归档追不上的处理升级前先把生产库的备份恢复到目标库并保持在 MOUNT 状态是保留回退能力的标准动作。这一步的报错比 DBUA 本身更致命因为它决定你有没有一个可用的源库副本。3.1 RMAN-06054media recovery requesting unknown archived logRMAN-03002: failure of recover command at 08/31/2022 21:40:31 RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 25197 and starting SCN of 18157927920这条报错的意思是控制文件记录的最新 SCN 之后还缺一个归档RMAN 想继续推但找不到。原因有三类备份集里归档不全、db_recovery_file_dest空间满导致归档被自动清理、或者控制文件是从旧备份恢复的里面记录的归档位置跟实际不符。# 先看备份集里到底有哪些归档看序列号断在哪 rman target / RMAN list backup of archivelog from time sysdate-1; # 把新拷过来的归档重新注册进控制文件 RMAN catalog start with /hisbak/; # 再确认一遍缺失序列 RMAN list archivelog all;排查顺序是「先 catalog再 list最后 recover」。很多情况下归档文件已经在/hisbak目录里了只是控制文件不知道catalog start with一跑就能续上。如果list backup of archivelog显示序列号中间有断档那就是备份环节漏了只能从源库补拷。3.2 追归档到某个时间点UNTIL TIME 的写法与坑手册里这段做得很细先restore database到2022-08-30:02:00:00再recover到07:00:00再往前推到12:00:00每推一次都重新startup mount。这个分步推进的思路是对的尤其对归档量大、需要边拷边恢复的场景。run { ALLOCATE CHANNEL C1 DEVICE TYPE DISK; ALLOCATE CHANNEL C2 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 C2; RELEASE CHANNEL C1; }%b是数据文件基名SET NEWNAME配合SWITCH DATABASE TO COPY可以把数据文件落到新路径避免源库文件系统路径在目标主机上不存在导致的ORA-19504。UNTIL TIME用的是数据库时区下的时间跟操作系统时区不一致时要特别小心差 8 小时是常见翻车点建议先用SELECT SYSDATE FROM DUAL;核一下库时间再写。已open read only的库要继续追归档必须先shutdown abort再startup mount不能直接 recover。手册里专门标了这一步很多人省掉它然后卡在ORA-01113: file 1 needs media recovery上。3.3 归档缺失的最后手段增量备份配合归档实在凑不齐时还有一条路从源库拿一份新的 incremental backup在目标库上做增量恢复把差距补上。前提是源库的 SCN 起点与目标库当前 SCN 能衔接。# 源库侧基于当前 SCN 做增量 RMAN backup incremental from scn 18157927920 database format /hisbak/incr_%U; # 目标库侧catalog 后应用 RMAN catalog start with /hisbak/; RMAN recover database noredo;recover database noredo只应用增量备份、不读归档适合作最后一次对齐。这个方式对归档保留策略不友好的老库尤其有用代价是要对源库再跑一次备份窗口得提前申请。3.4 恢复期间的三个参数绝不是摆设手册恢复参数文件那一节给了一串参数其中几个直接决定恢复成败参数值作用db_unique_namebsoftsb与源库区分避免 Data Guard 或路径冲突db_file_name_convert隐含在 NEWNAME 中源目标路径不一致时重定向文件db_recovery_file_dest_size200G空间不足会导致归档写入失败恢复中断control_file_record_keep_time15太小会让控制文件过早丢弃归档记录sec_case_sensitive_logonFALSE11g 默认升级到 19C 后密码策略会变更db_recovery_file_dest_size设小了是恢复阶段的高频故障表现是归档写着写着报ORA-19809。空间充足时给到 200G 是手册里的实际取值生产上按归档生成速率乘保留天数算更稳妥。注意恢复参数文件后要先create pfile from spfile改 port、路径、audit 目录之后再反向生成 spfile。直接改 spfile 二进制风险高而且出问题时没有任何可读的备份。4. DBUA 执行阶段失败ORA-32004 与组件无效的收尾预检查全绿、源库副本也就位了DBUA 真正跑起来之后仍然有坑。这一阶段报错的特点是「看着像失败其实是警告」和「看着像成功其实组件没编译过」。4.1 ORA-32004过时参数导致的启动失败ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance这条在 11g 升 19C 时几乎必现它不是一个错误而是提示你 pfile/spfile 里有 19C 已经不认的参数比如sec_case_sensitive_logon、audit_trailNONE的部分取值、resource_manager_plan的旧写法。-- 升级前先扫一遍过时参数 SELECT name, value FROM v$parameter WHERE isdeprecated TRUE; -- 常见需要清理的 -- sec_case_sensitive_logon19C 中已不可动态改建议升级前显式设为 FALSE 并固化 -- audit_trailNONE19C 推荐改为 DB 或 NONE 明确写法 -- _system_trig_enabled 等隐藏参数的遗留设置处理方式不是简单地把告警忽略而是在升级前把过时参数从 pfile 里删掉重新生成 spfile再启动源库确认业务正常。带着一堆过时参数进 DBUA升级完成后实例可能起不来那时候再回滚成本就高了。4.2 组件状态 INVALIDDBUA 报成功之后才是硬仗DBUA 到最后一步显示升级成功很多人就此收工第二天业务报错才发现DBA_REGISTRY里有组件是INVALID。11g 里装过的Oracle Text、OLAP、Spatial、XDB这些组件在 19C 上需要重新编译。-- 升级后必须查这一张表 SELECT comp_id, comp_name, version, status FROM dba_registry ORDER BY comp_id; -- 对无效组件逐个执行 ?/rdbms/admin/utlrp.sql -- 如果组件本身 INVALID先重装再编译例如 Oracle Text -- ?/ctx/admin/catctx.sql 需要按文档步骤执行utlrp.sql跑完再看dba_registry仍为INVALID的组件要按组件名单独处理而不是反复跑utlrp。典型场景是XDB或Oracle Text在升级时没有正确装载需要先catnoom之类的脚本清理再重装。升级后的验证清单里dba_registry、dba_objects无效对象数、dba_jobs、dba_scheduler_jobs这四项缺一不可。-- 无效对象数量正常应该接近 0 SELECT COUNT(*) FROM dba_objects WHERE status INVALID; -- 时区版本19C 要求升级后跑 utltz_upg_check.sql 确认 SELECT version FROM v$timezone_file;时区文件版本是另一个隐蔽项。11g 的时区版本与 19C 不同DBUA 会提示需要升级时区数据utltz_upg_check.sql检查通过后再跑utltz_upg_apply.sql。这一步不做涉及TIMESTAMP WITH TIME ZONE的查询会出现时间偏移而且极难排查。4.3 DBUA 静默模式无人值守升级的参数写法图形界面在跳板机上经常卡住或者渲染错位DBUA 支持静默执行适合有自动化需求的运维场景。# 先在图形模式下走一遍记录配置再导出响应文件 $ORACLE_HOME/bin/dbua -silent \ -sid bsoft \ -oracleHome /u01/app/oracle/product/19.14.0/db_1 \ -sysDBAUserName sys \ -sysDBAPassword *** \ -replayFile /home/oracle/dbua_replay.rsp \ -log /home/oracle/dbua_silent.log-replayFile是图形模式导出的响应文件里面记录了目标版本、时区升级、组件选择等选项。静默模式失败时日志在-log指定路径下报错信息比界面完整。跑静默升级前一定要确认ORACLE_HOME环境变量指向 19C 的目录否则 DBUA 会拿错软件版本做检查。4.4 升级后性能回退优化器统计信息必须重收集升级完成、组件也正常业务上线后反馈慢查询变多这通常是优化器统计信息没更新导致的。11g 的统计信息在 19C 优化器下参考价值下降加上 19C 默认开启了自动 SQL 计划管理行为可能和 11g 不一致。-- 升级后收集字典与固定对象统计信息 EXEC DBMS_STATS.GATHER_DICTIONARY_STATS; EXEC DBMS_STATS.GATHER_FIXED_OBJECTS_STATS; -- 保留 11g 的统计信息以便对比回退 EXEC DBMS_STATS.CREATE_STAT_TABLE(SYS,STATS_11G_BAK);GATHER_DICTIONARY_STATS建议在业务低峰跑耗时不短但必须做。另外把 11g 的统计信息导出到备份表万一执行计划大面积变化可以用DBMS_STATS.IMPORT_TABLE_STATS回灌对比这是排计划突变最省事的办法。5. 避坑清单五条升级现场的常见问题5.1 DBUA 跑到一半无响应界面卡在「正在执行升级脚本」现象进度条停在某个百分比十几分钟不动日志文件也没有新内容。 原因多数是TMPDIR空间不足或者 DBUA 内部调用的catupgrd.sql被锁等待阻塞。目标库如果还有别的会话连着升级脚本拿不到排他锁。 解决开另一个窗口tail -f $ORACLE_BASE/cfgtoollogs/dbua/*/upgrade*.log看到具体卡在哪个脚本确认df -h /tmp剩余空间大于 2Gshutdown immediate掉所有其他会话后重跑。别直接 kill DBUA 进程否则dba_registry可能留下中间状态。5.2 源库是生产环境恢复时把生产文件覆盖了现象在目标机上执行SET NEWNAME时漏了SWITCH DATABASE TO COPY恢复完没切文件后续open报找不到数据文件。 原因RESTORE只是把文件写到新路径控制文件里记录的还是老路径不SWITCH不会生效。 解决在run块里RESTORE之后紧跟SWITCH DATABASE TO COPY或者恢复后单独执行一次。执行前用REPORT SCHEMA确认所有文件名都落在/oradata/BSOFTSB/datafile/下。5.3 open read only 之后直接 recover报需要介质恢复现象只读打开库想继续追归档直接recover database报ORA-01113。 原因只读打开的库处于非 MOUNT 状态RMAN 无法执行恢复。 解决shutdown abort→startup mount→ 再recover。这个顺序不能省手册里专门写了这一条是很多人跳过的一步。5.4 升级后应用连不上报 ORA-01017 密码无效现象升级前能连的账号升级后密码验证失败。 原因11g 的sec_case_sensitive_logonFALSE与 19C 的密码大小写策略不兼容加上sqlnet.ora里的SQLNET.ALLOWED_LOGON_VERSION默认值被提高。 解决在sqlnet.ora里把SQLNET.ALLOWED_LOGON_VERSION_SERVER临时调低到 8 兼容老客户端同时让应用侧确认密码大小写长期方案是重置密码并统一为大小写敏感。5.5 升级完成后忘记更新监听与 tnsnames现象库起来了应用连的却是老库地址或者lsnrctl status里服务名对不上。 原因目标库的service_names沿用了源库配置或者监听器注册的还是旧ORACLE_HOME的服务。 解决lsnrctl status确认实例注册到正确的ORACLE_HOMEalter system register;手动触发注册必要时lsnrctl reload。别只看ps -ef | grep pmon进程在但服务没注册是两回事。6. 如何快速定位这类升级故障我的排查顺序从报错到根因我固定的顺序是「先看日志再看视图最后比对参数」。日志优先级DBUA 自身的$ORACLE_BASE/cfgtoollogs/dbua/sid/下的upgrade*.log和postupgrade*.logCVU 的cluvfy日志RMAN 的sbtio.log或命令输出。三份日志覆盖预检查、恢复、执行三个阶段任何一条报错都能在其中一份里找到上下文。视图优先级dba_registry看组件状态v$instance看版本v$parameter配合isdeprecatedTRUE扫过时参数dba_objects看无效对象。四张表查完升级是否真正成功基本心里有数。参数比对把升级前的 pfile 和升级后的 spfile 生成文本diff一次重点关注内存、字符集、时区、审计、密码策略这五类。差异项逐条确认是 DBUA 自动改的还是遗留的。-- 一条语句把升级后的健康状态拉出来 SELECT (SELECT version FROM v$instance) AS db_version, (SELECT COUNT(*) FROM dba_objects WHERE status INVALID) AS invalid_objects, (SELECT COUNT(*) FROM dba_registry WHERE status VALID) AS bad_components, (SELECT version FROM v$timezone_file) AS tz_version FROM dual;结果对照invalid_objects为 0 或个位数bad_components为 0tz_version与 19C 要求一致才算真正升级完成。任何一项不符回到对应章节找处理脚本不要直接开业务。最后说个教训。我早期做升级时把 DBUA 显示「升级成功」当成终点结果第二天客户报时间字段差了几小时查了半天才发现时区文件没升级。从那以后我每次升级完都强制走一遍验证 SQLdba_registry、无效对象、时区版本、监听注册这四项不通过就不交付。这套习惯配合这份手册里的恢复和追归档流程能让你在真正出问题时手里有据可查、有路可退。希望帮到你。本文还有配套的精品资源点击获取
