企业官网建设流程全解析

简介：这份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 源库到底能不能直接升到 19C

Oracle 的升级路径有硬性门槛。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在操作系统层面确认补丁。参数上重点看compatible，11g 上通常是 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 用的是 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，并列出预检查结果。关键步骤：

1. 选择源库：确认 SID 和ORACLE_HOME指向 11g。
2. 预检查：DBUA 会跑一遍检查，有警告不一定要停，但要逐条确认。时区版本警告通常可以升级后处理，无效对象警告最好升级前修掉。
3. 升级选项：选择「升级现有数据库」，不要选「复制数据库」。
4. 并行度：默认值通常够用，如果 CPU 核多可以调到 4 或 8，但不要超过 CPU 核数。
5. 恢复选项：勾选「启用 RMAN 备份」，DBUA 会在升级前自动做一次备份，这是额外的保险。
6. 网络配置：监听端口默认 1521，如果 11g 用的是非标准端口，这里要改一致。
7. 口令管理：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.sql

utlrp.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_SID=orcl11g 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_servers=8 SCOPE=MEMORY; @?/rdbms/admin/catupgrd.sql

catupgrd.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为TRUE，11g 默认不区分大小写。解决：升级前确认应用密码大小写，如果应用用小写密码，升级后要么改密码，要么临时把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.4，19C 的新特性被禁用。解决：确认应用兼容后，把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都备份一份，升级后如果监听起不来，直接对比文件差异，比从头排查快得多。升级这件事，后悔药只有备份和回退方案，没有捷径。希望帮到你。

本文还有配套的精品资源，点击获取