Oracle 11g 升级 19C 实战手册：DBUA 与静默升级全流程

简介这份PDF手册面向具备一定运维能力的数据库管理员聚焦如何借助DBUA工具将Oracle 11g安全升级至19C解决旧版本停止补丁更新后的迁移与合规问题。内容覆盖前期备份与恢复、升级路线选择、环境说明、参数文件恢复及必要配置调整并强调检查脚本日志与警告、严格遵循操作顺序同时附有多个故障解决方案应对升级异常。资源包共1个PDF文件大小约3.18MB结构紧凑便于按章节查阅与对照实操。目前已有1345人学习下载适合需要完成11g到19C迁移的DBA参考。读者可从中获得完整的升级流程框架、RMAN备份恢复与归档追平思路、DBUA静默方式及MOS参考文档索引以及针对升级失败回退和常见报错的排查方向帮助在维护窗口内更稳妥地推进数据库升级。1. Oracle 11g 到 19C 升级一次没有后悔药的版本跃迁生产库还跑在 11g 上业务侧已经在问「19C 的 JSON 支持和分区增强能不能用上」而 DBA 最怕的不是升级本身是升级到一半发现某个存储过程编译不过、某个 EBS WIP 非标工单的接口突然报错。Oracle 11g 到 19C 不是打一个补丁中间跨了 12c、18c 两个大版本优化器、字符集、默认参数、数据字典都变了。这篇手册面向的是手里有 11g 生产库、需要规划一次可控升级的 DBA 和运维工程师也适合正在做 19c RAC 安装步骤调研、想先把单机升级路径摸清楚的人。我会把 DBUA 图形化和命令行两条路都拆开把参数、脚本、回退方案和踩坑记录写清楚让你看完能直接排期动手而不是停在「知道要升级」这一步。2. 升级前的环境盘点与兼容性检查别让 DBUA 替你发现地雷2.1 先确认 11g 源库到底能不能直接升到 19COracle 的升级路径有硬性门槛。11.2.0.4 是能直接升到 19C 的最低 11g 版本如果你还在 11.2.0.1 到 11.2.0.3必须先补到 11.2.0.4 再谈升级。这一步不是可选项DBUA 在预检查阶段就会拦你。常见做法是先查源库版本和补丁集-- 查看当前数据库版本和补丁信息 SELECT * FROM v$version; SELECT version, bundle_series, description FROM dba_registry_sqlpatch ORDER BY action_time DESC;v$version返回的版本号如果低于 11.2.0.4升级路径就要重新规划。dba_registry_sqlpatch在 11g 上可能不存在那就退回到opatch lsinventory在操作系统层面确认补丁。参数上重点看compatible11g 上通常是 11.2.0.4升级到 19C 后这个参数不能低于 11.2.0.4否则某些新特性无法启用。除了版本还要跑一遍 Oracle 官方的预升级脚本。19C 的介质里自带preupgrade.jar位置在$ORACLE_HOME/jdk/bin或$ORACLE_HOME/rdbms/admin下。执行方式# 在 11g 源库上执行预升级检查生成报告 $ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/rdbms/admin/preupgrade.jar FILE TEXT DIR /tmp/preupgrade执行完会在/tmp/preupgrade下生成preupgrade.log和preupgrade_fixups.sql。preupgrade_fixups.sql是必须在升级前跑掉的修复脚本里面通常包含无效对象清理、字符集检查、COMPATIBLE参数调整建议。我一般会把这个脚本在测试库先跑一遍确认没有报错再上生产。2.2 用 DBUA 预检查还是手工脚本两条路的取舍DBUA 在 19C 里已经比较成熟图形化界面能自动完成大部分预检查包括时区版本、字符集兼容性、无效对象、组件版本。但 DBUA 的预检查是黑匣子它告诉你「有问题」但不一定告诉你「为什么」。我的习惯是先用preupgrade.jar跑一遍拿到完整报告再用 DBUA 做实际升级两者互补。预检查阶段要重点关注的几类问题检查项常见问题处理方式时区版本11g 时区文件版本低于 19C 要求升级前打时区补丁或升级后用DBMS_DST更新字符集源库字符集不是 AL32UTF8升级不强制改字符集但跨字符集迁移要单独规划无效对象存储过程、视图编译失败升级前重新编译或记录后升级后处理组件版本XDB、OLS、APEX 等组件过旧按预升级报告逐个升级或删除不用的组件密码大小写11g 默认密码不区分大小写19C 默认区分需确认应用连接串字符集这块特别容易翻车。如果 11g 用的是 ZHS16GBK升级到 19C 后数据库字符集不会自动变但新建的库如果选 AL32UTF8跨库数据同步时中文可能乱码。常见做法是升级前确认字符集如果业务允许在升级窗口内一并做字符集转换但这会显著拉长停机时间要提前评估。2.3 备份策略没有回退方案的升级就是赌博升级前必须有一份可回退的备份。RMAN 全备加归档日志是底线如果停机窗口允许最好做一次冷备。19C 升级后数据字典变化很大一旦升级失败靠闪回或 Data Guard 切换回 11g 的窗口很窄。# 升级前 RMAN 全备保留归档 rman target / BACKUP DATABASE PLUS ARCHIVELOG; BACKUP CURRENT CONTROLFILE;备份完成后验证备份可读别等到要回退时才发现备份损坏。如果生产库有 Data Guard可以考虑先升级备库再切换但 11g 到 19C 的 Data Guard 跨版本角色切换限制较多常见做法还是停机窗口内原地升级备库作为回退兜底。3. DBUA 图形化升级全流程从 11g 到 19C 的每一步3.1 安装 19C 软件并准备升级环境升级不是覆盖安装19C 的 Oracle Home 要和 11g 分开。先在目标服务器上安装 19C 软件只装软件不建库。安装时注意操作系统用户和 11g 保持一致通常是oracle避免权限混乱。19C 的ORACLE_BASE可以和 11g 共用但ORACLE_HOME必须独立比如/u01/app/oracle/product/19.0.0/dbhome_1。安装类型选「仅安装软件」不要选「创建并配置数据库」。安装完成后把 19C 的ORACLE_HOME、PATH、LD_LIBRARY_PATH配好但不要急着改全局环境变量升级时用独立终端会话切换。# 切换到 19C 环境准备运行 DBUA export ORACLE_HOME/u01/app/oracle/product/19.0.0/dbhome_1 export PATH$ORACLE_HOME/bin:$PATH export LD_LIBRARY_PATH$ORACLE_HOME/lib:$LD_LIBRARY_PATH环境变量切换后用$ORACLE_HOME/bin/dbua启动图形界面。如果服务器没有图形环境可以用静默模式但静默模式的参数文件容易写错我一般建议至少用 X11 转发跑一次图形化看清楚每一步在做什么。3.2 DBUA 操作步骤与关键参数DBUA 启动后选择「升级数据库」然后指定 11g 的 SID。DBUA 会自动读取 11g 的spfile或pfile并列出预检查结果。关键步骤选择源库确认 SID 和ORACLE_HOME指向 11g。预检查DBUA 会跑一遍检查有警告不一定要停但要逐条确认。时区版本警告通常可以升级后处理无效对象警告最好升级前修掉。升级选项选择「升级现有数据库」不要选「复制数据库」。并行度默认值通常够用如果 CPU 核多可以调到 4 或 8但不要超过 CPU 核数。恢复选项勾选「启用 RMAN 备份」DBUA 会在升级前自动做一次备份这是额外的保险。网络配置监听端口默认 1521如果 11g 用的是非标准端口这里要改一致。口令管理19C 默认区分大小写如果应用连接串里密码是小写这里要确认。DBUA 执行过程中会调用catupgrd.sql等脚本时间取决于数据字典大小和组件数量一般 30 分钟到 2 小时。执行期间不要中断中断后恢复很麻烦。3.3 升级后验证别只看 DBUA 说成功DBUA 最后显示「升级成功」不代表万事大吉。升级后必须手工验证-- 检查升级后版本和组件状态 SELECT * FROM v$version; SELECT comp_name, version, status FROM dba_registry ORDER BY comp_name; -- 检查无效对象 SELECT owner, object_name, object_type FROM dba_objects WHERE status INVALID; -- 检查时区版本 SELECT * FROM v$timezone_file;dba_registry里所有组件状态应该是VALID如果有INVALID或LOADING要单独处理。无效对象如果集中在某个 schema通常是该 schema 的存储过程或视图引用了旧版本特性重新编译即可-- 重新编译无效对象 ?/rdbms/admin/utlrp.sqlutlrp.sql跑完后再次查dba_objects如果还有无效对象就要逐个看编译错误。常见原因是 11g 的存储过程里用了 19C 已废弃的语法或者引用了不存在的包。4. 命令行静默升级没有图形界面时怎么把活干完4.1 静默升级的适用场景与前置条件很多生产服务器不装图形环境DBUA 图形化跑不起来。这时候可以用 DBUA 静默模式或者手工执行升级脚本。DBUA 静默模式需要写一个响应文件参数多且容易错我一般只在批量升级时用。单库升级更推荐手工执行步骤透明出问题好定位。手工升级的核心是用 19C 的ORACLE_HOME启动 11g 的实例然后执行升级脚本。前提是 11g 的spfile能被 19C 识别且COMPATIBLE参数不低于 11.2.0.4。# 用 19C 环境启动 11g 实例准备升级 export ORACLE_HOME/u01/app/oracle/product/19.0.0/dbhome_1 export PATH$ORACLE_HOME/bin:$PATH export ORACLE_SIDorcl11g sqlplus / as sysdba在 SQL*Plus 里启动实例到UPGRADE模式-- 启动到升级模式 STARTUP UPGRADE; -- 确认实例状态 SELECT status FROM v$instance;v$instance状态应该是OPEN MIGRATE或STARTED具体取决于版本。如果启动报错通常是spfile路径不对或参数不兼容需要先用 11g 环境生成pfile改好后再用 19C 启动。4.2 执行升级脚本与并行参数启动到升级模式后执行 19C 的升级脚本-- 执行升级脚本设置并行度 ALTER SYSTEM SET parallel_max_servers8 SCOPEMEMORY; ?/rdbms/admin/catupgrd.sqlcatupgrd.sql会依次调用多个脚本执行时间较长。并行度parallel_max_servers根据 CPU 核数设置一般 8 到 16 够用设太大反而可能因为资源争抢变慢。执行过程中如果报错脚本会继续跑最后统一输出错误日志。日志位置在$ORACLE_BASE/cfgtoollogs/catupgrd下升级完成后要逐条看。升级脚本跑完后实例会停在OPEN MIGRATE状态需要重启到正常模式-- 重启数据库到正常模式 SHUTDOWN IMMEDIATE; STARTUP; -- 重新编译无效对象 ?/rdbms/admin/utlrp.sql重启后检查dba_registry和dba_objects确认组件和对象状态。如果catupgrd.sql中途报错退出不要直接重跑先看日志定位问题修复后再从断点继续。4.3 升级后参数调整与监听配置19C 的默认参数和 11g 有差异升级后要检查几个关键参数-- 检查关键参数 SHOW PARAMETER compatible; SHOW PARAMETER optimizer_features_enable; SHOW PARAMETER sga_target; SHOW PARAMETER pga_aggregate_target;compatible升级后通常还是 11.2.0.4如果要启用 19C 新特性需要改成 19.0.0但改之前要确认应用兼容。optimizer_features_enable如果还是 11.2.0.4优化器行为会保持 11g 风格升级后可以先不动观察一段时间再改。监听配置也要更新。19C 的监听器配置文件和 11g 格式兼容但listener.ora里的ORACLE_HOME要指向 19C。如果监听服务无法启动常见原因是ORACLE_HOME路径不对或端口被占用。# 检查监听状态 lsnrctl status # 如果监听没起来用 19C 环境启动 lsnrctl start监听日志如果太大可以清理但不要直接删正在写的日志文件用lsnrctl set log_status off暂停后再处理。5. 升级避坑清单五条血泪经验5.1 时区版本不匹配导致DBMS_SCHEDULER报错现象升级后创建定时任务报ORA-01804或时区相关错误。原因11g 的时区文件版本低于 19C 要求DBMS_SCHEDULER和DBMS_DST依赖时区数据。解决升级前查SELECT * FROM v$timezone_file如果版本低于 19C 介质里的版本先打时区补丁升级后用DBMS_DST更新。5.2 密码大小写敏感导致应用连接失败现象升级后应用连接串报ORA-01017但密码没改。原因19C 默认sec_case_sensitive_logon为TRUE11g 默认不区分大小写。解决升级前确认应用密码大小写如果应用用小写密码升级后要么改密码要么临时把sec_case_sensitive_logon设为FALSE但这不是长久之计。5.3 无效对象集中在 EBS 相关 schema现象升级后dba_objects里 EBS 的 WIP 非标工单相关存储过程大量无效。原因EBS 的存储过程引用了 11g 特有的包或语法19C 里行为变了。解决升级前在测试库跑一遍 EBS 核心流程记录无效对象升级后逐个重新编译必要时打 EBS 的 19C 兼容补丁。5.4COMPATIBLE参数没改导致新特性不可用现象升级到 19C 后想用自动索引或 JSON 增强发现不支持。原因COMPATIBLE还是 11.2.0.419C 的新特性被禁用。解决确认应用兼容后把COMPATIBLE改成 19.0.0改完需要重启。改之前做一次全备因为COMPATIBLE降回去很麻烦。5.5 监听日志占满磁盘导致监听无法启动现象升级后监听服务无法启动报磁盘空间不足。原因11g 的监听日志长期没清理listener.log几个 GB。解决升级前清理监听日志用lsnrctl set log_status off暂停日志移走旧文件后再开启。19C 的监听日志默认路径和 11g 可能不同升级后确认ADR基目录。6. 升级后的性能验证与回退窗口管理升级完成不代表结束真正的考验在升级后第一周。我一般会在升级后立刻跑一轮性能基线对比用 11g 时期的 AWR 报告和 19C 的对比重点看DB Time、Top 10 Foreground Events、SQL ordered by Elapsed Time。如果发现某条 SQL 执行计划突变先别急着改 SQL用SQL Plan Baseline把 11g 的计划固定住观察几天再决定是否让优化器用新计划。-- 从 11g AWR 里导出 SQL Plan Baseline在 19C 上加载 -- 11g 上执行 SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR(sql_id)); -- 19C 上加载基线 DECLARE l_plans_loaded PLS_INTEGER; BEGIN l_plans_loaded : DBMS_SPM.LOAD_PLANS_FROM_AWR( begin_snap begin_snap, end_snap end_snap, basic_filter sql_id sql_id ); DBMS_OUTPUT.PUT_LINE(Plans loaded: || l_plans_loaded); END; /DBMS_SPM.LOAD_PLANS_FROM_AWR的参数begin_snap和end_snap是 11g AWR 快照号basic_filter里指定 SQL ID。加载后 19C 优化器会优先用基线里的计划避免计划突变导致的性能回退。这个操作在升级后一周内做最有效等新计划跑久了再固定就晚了。回退窗口的管理同样重要。升级后至少保留 11g 的全备和归档两周确认业务无异常后再清理。如果升级后出现严重问题需要回退流程是停 19C 实例用 11g 的ORACLE_HOME启动原库恢复升级前的控制文件和spfile。但回退后升级期间的数据会丢失所以升级窗口内最好停业务避免数据不一致。我自己的习惯是升级前把 11g 的spfile、listener.ora、tnsnames.ora和oratab都备份一份升级后如果监听起不来直接对比文件差异比从头排查快得多。升级这件事后悔药只有备份和回退方案没有捷径。希望帮到你。本文还有配套的精品资源点击获取