简介这份PDF手册面向具备一定运维能力的数据库管理员聚焦如何借助DBUA工具将Oracle 11g安全升级至19C解决旧版本停止补丁更新后的迁移与合规问题。内容覆盖升级路线判定、RMAN备份恢复、参数文件调整、DBUA执行流程及日志与警告检查并附有多个故障解决方案帮助应对升级中的异常情形。资源包为1个PDF文件大小约3.18MB单文件结构便于集中查阅与打印适合作为升级实施时的案头参考。目前已有1345人学习下载说明其在DBA群体中具备一定参考价值。读者可从中获得从11g到19C的完整升级思路、关键命令细节与注意事项尤其适合需要保留生产环境用于失败回退、通过备份恢复到目标库再执行升级的维护场景从而提升数据库性能与安全性契合未来软件架构发展趋势。1. 从 11g 到 19C为什么 DBUA 是单机升级最稳的那条路手上还跑着 11.2.0.4 的库补丁停了官方支持也到期了业务侧又催着要上 19C 的新特性——这种局面下升级不是要不要做的问题而是怎么做得不翻车的问题。Oracle 19C 是长期支持版本官方给的单机升级路径里DBUADatabase Upgrade Assistant是图形化引导最完整、检查项最全的一种。它把升级前检查、参数调整、组件重编译、时区文件升级这些容易漏的环节串成一条流水线比手工跑脚本少踩很多坑。这份手册针对的场景很明确11g 单机通过 DBUA 升级到 19C源库是生产环境目标库是独立的升级环境。核心思路是先用 RMAN 把生产库恢复到目标主机保留生产库作为回退兜底再在目标库上跑 DBUA。适合有一定运维基础的 DBA新手照着步骤也能走通但每一步的参数含义和失败信号必须看懂否则出了问题连日志在哪都不知道。2. 升级前的硬性门槛版本路线、主机要求与 RMAN 恢复2.1 先确认你的版本能不能直达 19CDBUA 不是万能的版本跨度太大它也不接。Oracle 官方给的升级路线分两种直接升级和间接升级。直接升级的意思是源库版本够高一步到位间接升级则要先升到中间版本再往 19C 走。源库版本升级路径目标版本11.2.0.4 及以上直接升级19.x12.1.0.2直接升级19.x12.2.0.1直接升级19.x18.1直接升级19.x11.2.0.1 / 11.2.0.2 / 11.2.0.3先升到 11.2.0.419.x11.1.0.6 / 11.1.0.7先升到 11.2.0.419.x10.2.0.2 10.2.0.5先升到 11.2.0.4 或 12.1.0.219.x10.1.0.5先升到 11.2.0.4 或 12.1.0.219.x9.2.0.8 或更早先升到 11.2.0.419.x12.1.0.1先升到 12.1.0.2 或 12.2.0.119.x这张表是选型的第一道关。如果你手上是 11.2.0.4恭喜可以直接上 DBUA。如果是 11.2.0.3 甚至更早别想着跳过中间版本DBUA 会直接拒绝硬来只会浪费时间。2.2 主机版本不够 Linux 7 就得换机器19C 对操作系统的最低要求是 Linux 7。如果源库跑在 Linux 6 上不是升级数据库那么简单得先准备一台 Linux 7 的新主机在上面装好 19C 的 Oracle Home再把数据迁过去。这一步没有捷径DBUA 不会帮你跨操作系统版本。环境规划上源库和目标库分开部署是明智的。源库继续跑生产目标库用来做升级验证。这样即使升级失败生产库还在业务不受影响。目标库的 ORACLE_HOME 指向 19C 的安装目录源库的 ORACLE_HOME 保持 11g 不动两边通过 RMAN 备份文件传递数据。2.3 用 RMAN 把生产库恢复到目标库恢复是升级的前置动作目的是在目标库上得到一个和源库结构一致、数据可追平的实例。整个恢复过程分几步恢复参数文件、恢复控制文件、加载备份、恢复数据文件、追归档。先恢复参数文件启动到 nomount 状态# 切换到 oracle 用户加载环境变量 source .bash_profile # 进入 RMAN从备份中恢复 spfile rman target / RMAN startup nomount; RMAN restore spfile from /hisbak/spfile_BSOFT_562120512_20220830_40444.ora; # 从 spfile 生成 pfile方便手工调整参数 SQL create pfile/home/oracle/pfile.ora from spfile; SQL exit;参数文件恢复后需要根据目标库的目录结构修改 pfile 里的路径。比如 audit_file_dest、control_files、db_recovery_file_dest 这些指向具体目录的参数必须改成目标库实际存在的路径。改完后用 pfile 启动到 nomount再生成目标库的 spfile# 创建必要的目录 mkdir -p /u02/app/oracle/admin/bsoftsb/adump mkdir -p /oradata/bsoftsb/controlfile/ # 编辑 pfile调整路径参数 vim /home/oracle/pfile.ora # 用 pfile 启动到 nomount SQL startup nomount pfile/home/oracle/pfile.ora; # 生成目标库的 spfile SQL CREATE SPFILE/u02/app/oracle/product/11.2.0/db/dbs/spfilebsoft.ora FROM PFILE/home/oracle/pfile.ora;参数调整的逻辑是源库和目标库的目录结构可能不同pfile 里的路径必须全部指向目标库的真实路径。db_name 保持不变db_unique_name 可以改成目标库的标识避免和源库冲突。memory_target、sga_target 这些内存参数根据目标主机的物理内存调整不要照搬源库的值。接下来恢复控制文件并 mountrman target / # 从备份恢复控制文件 RMAN restore controlfile from /hisbak/BSOFT_CONT_562120512_20220830_40443.ctl; # 挂载数据库 RMAN sql alter database mount; # 加载备份目录下的所有备份片 RMAN catalog start with /hisbak/;控制文件恢复后RMAN 需要知道备份文件的位置catalog start with 就是让 RMAN 扫描指定目录把备份片信息注册到控制文件里。这一步做完可以用 REPORT SCHEMA 查看数据文件和临时文件列表确认所有文件都能识别到。恢复数据文件时用 SET NEWNAME 把文件重定向到目标库的路径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/BSOFTSB/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 里的 %b 是通配符表示保留原文件名。SET UNTIL TIME 指定恢复的时间点这里选的是备份时间点。RESTORE DATABASE 只恢复数据文件不涉及归档。通道数根据目标主机的 I/O 能力调整一般 4 到 8 个够用太多反而会争抢资源。恢复完成后切换到数据文件副本并追归档# 切换数据文件到新路径 RMAN SWITCH DATABASE TO COPY; # 追归档到指定时间点 run { ALLOCATE CHANNEL C1 DEVICE TYPE DISK; ALLOCATE CHANNEL C2 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; }RECOVER DATABASE 会应用归档日志把数据库推进到指定时间点。如果归档不够可以分多次追每次指定不同的时间点。追到某个时间点后用alter database open read only打开数据库验证数据确认没问题再继续往前追。这种打开只读→关闭→继续追的方式可以在不写入数据的前提下反复验证恢复结果。注意每次追归档前如果数据库已经 open read only必须先shutdown abort再startup mount否则 RECOVER 会报错。3. DBUA 升级实操从启动向导到组件重编译3.1 启动 DBUA 前的检查清单DBUA 启动前有几项检查必须手工做完否则向导跑到一半报错排查起来很麻烦。第一确认源库没有无效对象。升级过程中 DBUA 会重编译所有对象如果有无效对象重编译会失败。用utlrp.sql先跑一遍-- 检查无效对象数量 SELECT COUNT(*) FROM dba_objects WHERE status INVALID; -- 如果有无效对象执行重编译脚本 ?/rdbms/admin/utlrp.sql -- 再次检查确认无效对象已清零 SELECT COUNT(*) FROM dba_objects WHERE status INVALID;第二检查时区文件版本。11g 和 19C 的时区文件版本可能不同如果源库的时区文件版本低于 19C 的要求DBUA 会提示先升级时区文件。用以下 SQL 查看当前版本SELECT version FROM v$timezone_file;如果版本低于 19C 的要求需要用DBMS_DST包升级时区文件。这一步在源库上做做完再备份否则恢复到目标库后还得重做。第三确认字符集兼容。19C 对字符集的要求比 11g 严格如果源库用了过时的字符集升级会失败。用以下 SQL 检查SELECT parameter, value FROM nls_database_parameters WHERE parameter IN (NLS_CHARACTERSET, NLS_NCHAR_CHARACTERSET);常见的安全字符集是 AL32UTF8 和 ZHS16GBK。如果源库用的是 WE8ISO8859P1 之类的字符集升级前需要先转换这一步风险较高建议单独评估。第四检查是否有重复的 db_name 或 db_unique_name。目标库和源库如果在同一网络内db_unique_name 必须不同否则 Data Guard 或 RMAN 会混淆。用以下 SQL 确认SELECT name, db_unique_name FROM v$database;3.2 DBUA 图形化向导的关键参数DBUA 的启动方式很简单在 19C 的 ORACLE_HOME 下执行# 切换到 19C 的 Oracle Home export ORACLE_HOME/u02/app/oracle/product/19.14.0/db_1 export PATH$ORACLE_HOME/bin:$PATH # 启动 DBUA dbua向导启动后第一步是选择要升级的数据库。DBUA 会自动检测当前主机上的 11g 实例如果检测不到可以手工指定 ORACLE_HOME 和 SID。选择数据库后向导会做一系列预检查包括数据库版本是否支持直接升级是否有足够的磁盘空间是否有无效对象时区文件版本是否兼容字符集是否兼容是否有重复的 db_name预检查通过后进入参数配置页面。这里有几个关键参数需要确认并行度Degree of Parallelism默认是 4根据目标主机的 CPU 核数调整。核数多可以调到 8 或 16核数少就保持 4 或降到 2。并行度太高会导致资源争抢太低会拉长升级时间。恢复选项Recovery OptionsDBUA 默认会启用 Flashback Drop 和 Guaranteed Restore Point。Guaranteed Restore Point 会在升级前创建一个恢复点如果升级失败可以快速回退。这个选项建议开启代价是升级期间需要额外的磁盘空间。网络配置DBUA 会提示是否修改监听器配置。如果目标库的监听器和源库不同需要在这里指定新的监听器端口和服务名。升级完成后监听器会自动注册新服务。升级选项包括是否升级时区文件、是否重编译无效对象、是否升级 EM 配置。时区文件升级建议勾选重编译无效对象也建议勾选EM 配置根据实际需要选择。配置完成后DBUA 会生成一个升级摘要列出所有将要执行的操作。仔细核对摘要确认没有遗漏。然后点击FinishDBUA 开始执行升级。3.3 升级过程中的日志与警告处理DBUA 执行升级时会在后台跑一系列脚本。这些脚本的日志存放在$ORACLE_BASE/cfgtoollogs/dbua/目录下按时间戳分目录存放。升级过程中如果卡住第一时间去看日志。常见的日志文件包括dbua.logDBUA 主日志记录每一步的操作和结果preupgrade.log升级前检查日志记录预检查的详细结果postupgrade.log升级后操作日志记录组件重编译和时区升级的结果catupgrd.log数据字典升级日志记录核心组件的升级过程升级过程中最常见的警告是无效对象和组件版本不匹配。无效对象在预检查阶段就应该处理掉如果升级过程中又出现通常是某些依赖对象的编译顺序问题等升级完成后跑一遍utlrp.sql就能解决。组件版本不匹配通常是某些组件没有升级到 19C 的版本需要在升级完成后手工执行组件的升级脚本。DBUA 升级完成后会弹出一个结果页面列出升级成功的组件和失败的组件。失败的组件需要手工处理每个组件都有对应的升级脚本在$ORACLE_HOME/rdbms/admin/目录下。比如 Oracle Text 组件的升级脚本是catctx.sql执行方式-- 升级 Oracle Text 组件 SQL ?/ctx/admin/catctx.sql升级完成后用以下 SQL 确认组件版本SELECT comp_name, version, status FROM dba_registry;所有组件的 status 应该是 VALIDversion 应该是 19.x。如果有 INVALID 或版本不对需要单独处理。3.4 升级后的验证与回退准备升级完成后不要急着把业务切过来。先做几项验证第一检查数据库是否能正常启动和关闭。用shutdown immediate和startup反复几次确认没有报错。第二检查关键业务表是否能正常访问。随机抽取几张核心表做SELECT COUNT(*)和简单的 JOIN 查询确认数据完整。第三检查存储过程、函数、触发器等 PL/SQL 对象是否能正常编译和执行。用以下 SQL 检查无效对象SELECT owner, object_name, object_type FROM dba_objects WHERE status INVALID AND owner NOT IN (SYS, SYSTEM);第四检查监听器是否能正常注册服务。用lsnrctl status查看服务名和端口确认和预期一致。回退准备方面源库保持不动是最重要的兜底。如果升级后的目标库有问题业务可以切回源库。另外DBUA 在升级前创建的 Guaranteed Restore Point 也可以用来快速回退-- 查看恢复点 SELECT name, scn, time FROM v$restore_point; -- 回退到恢复点 SQL startup mount; RMAN FLASHBACK DATABASE TO RESTORE POINT BEFORE_UPGRADE; RMAN ALTER DATABASE OPEN RESETLOGS;回退操作会丢失升级后的所有变更所以只适合升级后立即发现问题的场景。如果升级后已经跑了业务回退前需要评估数据丢失的影响。4. 避坑指南DBUA 升级中最容易翻车的五个点4.1 预检查报无效对象但 utlrp 跑不通现象DBUA 预检查提示有无效对象执行utlrp.sql后无效对象数量没减少或者报错中断。原因无效对象之间存在依赖关系utlrp.sql按顺序编译时如果某个底层对象编译失败依赖它的上层对象也会失败。常见的是某些自定义类型或包依赖了过时的系统包。解决先用dba_objects查出所有无效对象按 owner 和 object_type 分组手工逐个编译。对于依赖系统包的无效对象先确认系统包是否有效如果系统包本身无效需要先重编译系统包。用以下 SQL 查看无效对象的依赖关系SELECT owner, object_name, object_type FROM dba_objects WHERE status INVALID ORDER BY owner, object_type, object_name;4.2 时区文件版本不兼容导致升级中断现象DBUA 升级到一半报错提示时区文件版本不匹配升级中断。原因11g 的时区文件版本低于 19C 的要求DBUA 在升级过程中需要更新时区文件但如果源库的时区文件版本太低更新会失败。解决在源库上先升级时区文件再重新备份和恢复。升级时区文件用DBMS_DST包步骤如下-- 检查当前时区文件版本 SELECT version FROM v$timezone_file; -- 准备升级时区文件 EXEC DBMS_DST.BEGIN_PREPARE(32); -- 执行升级 EXEC DBMS_DST.BEGIN_UPGRADE(32); -- 检查是否有错误 SELECT * FROM dba_dst_errors; -- 结束升级 EXEC DBMS_DST.END_UPGRADE(32);时区文件升级需要在源库上做做完后重新备份再恢复到目标库。这一步比较耗时建议在业务低峰期做。4.3 恢复数据文件时路径映射错误现象RMAN 恢复数据文件时报错提示无法创建文件或路径不存在。原因SET NEWNAME里的路径映射不对或者目标路径没有提前创建。常见的是%b通配符展开后的文件名和实际目录结构不匹配。解决先用REPORT SCHEMA查看源库的数据文件列表确认每个文件的原始路径。然后检查SET NEWNAME的目标路径是否存在权限是否正确。如果目录结构复杂可以先用SET NEWNAME FOR DATAFILE逐个指定确认无误后再用SET NEWNAME FOR DATABASE批量映射。-- 查看数据文件列表 RMAN REPORT SCHEMA; -- 逐个指定新路径 RMAN SET NEWNAME FOR DATAFILE 1 TO /oradata/BSOFTSB/datafile/system01.dbf; RMAN SET NEWNAME FOR DATAFILE 2 TO /oradata/BSOFTSB/datafile/sysaux01.dbf;4.4 升级后监听器无法注册服务现象升级完成后lsnrctl status看不到新服务客户端连接报ORA-12514: TNS:listener does not currently know of service requested。原因19C 的service_names参数和 11g 不同或者监听器配置没有更新。另外如果目标库的local_listener参数指向了错误的监听器地址服务也不会注册。解决检查service_names和local_listener参数SHOW PARAMETER service_names; SHOW PARAMETER local_listener;如果local_listener为空手工设置ALTER SYSTEM SET local_listener(ADDRESS(PROTOCOLTCP)(HOST192.168.6.132)(PORT1521)); ALTER SYSTEM REGISTER;然后重启监听器确认服务注册成功。4.5 升级后存储过程编译失败现象升级完成后部分存储过程、函数、触发器状态为 INVALID手工编译也失败。原因19C 对 PL/SQL 的语法检查更严格11g 下能编译通过的代码在 19C 下可能报错。常见的是隐式类型转换、过时的包引用、权限不足。解决用SHOW ERRORS查看具体错误SHOW ERRORS PROCEDURE owner.procedure_name;根据错误信息逐个修复。如果是权限问题检查对象的执行权限是否在升级过程中丢失。如果是语法问题修改代码后重新编译。对于大量无效对象可以写一个脚本批量编译BEGIN FOR obj IN (SELECT owner, object_name, object_type FROM dba_objects WHERE status INVALID AND owner NOT IN (SYS, SYSTEM)) LOOP BEGIN EXECUTE IMMEDIATE ALTER || obj.object_type || || obj.owner || . || obj.object_name || COMPILE; EXCEPTION WHEN OTHERS THEN DBMS_OUTPUT.PUT_LINE(Failed: || obj.owner || . || obj.object_name); END; END LOOP; END; /5. 静默升级与批量验证把 DBUA 塞进自动化流程图形化 DBUA 适合单次升级但如果手上有多个 11g 实例要升一个个点向导效率太低。DBUA 支持静默模式可以用命令行参数驱动配合响应文件实现批量升级。静默模式的参考文档是 MOS 2548985.1核心命令是# 静默模式启动 DBUA dbua -silent -sid bsoft -oracleHome /u02/app/oracle/product/19.14.0/db_1 \ -sysPassword password -systemPassword password \ -upgradeTimezone true -recompileInvalidObjects true \ -createGRP true -backupLocation /backup/dbua参数说明-sid指定要升级的实例-oracleHome指定 19C 的 ORACLE_HOME-sysPassword和-systemPassword是源库的密码-upgradeTimezone控制是否升级时区文件-recompileInvalidObjects控制是否重编译无效对象-createGRP控制是否创建 Guaranteed Restore Point-backupLocation指定备份目录。静默模式的日志默认输出到$ORACLE_BASE/cfgtoollogs/dbua/下可以用-logdir参数指定其他目录。升级完成后用以下命令检查结果# 查看升级摘要 cat $ORACLE_BASE/cfgtoollogs/dbua/timestamp/dbua.log | grep -i success\|fail # 检查组件版本 sqlplus / as sysdba EOF SELECT comp_name, version, status FROM dba_registry; SELECT COUNT(*) FROM dba_objects WHERE status INVALID; EOF批量升级时可以把每个实例的升级命令写进脚本用循环依次执行。每个实例升级完成后立即做验证确认无误再升下一个。这样即使某个实例出问题也不会影响其他实例。验证环节我一般会跑一个冒烟测试脚本覆盖数据库启动、关键表查询、存储过程执行、监听器注册这几项-- 冒烟测试脚本 SET SERVEROUTPUT ON; -- 1. 检查数据库状态 SELECT status FROM v$instance; -- 2. 检查组件版本 SELECT comp_name, version, status FROM dba_registry WHERE status ! VALID; -- 3. 检查无效对象 SELECT COUNT(*) FROM dba_objects WHERE status INVALID AND owner NOT IN (SYS, SYSTEM); -- 4. 检查关键表 SELECT COUNT(*) FROM bsoft.portal_his WHERE rownum 1; -- 5. 检查存储过程 BEGIN bsoft.some_procedure; DBMS_OUTPUT.PUT_LINE(Procedure executed successfully); EXCEPTION WHEN OTHERS THEN DBMS_OUTPUT.PUT_LINE(Procedure failed: || SQLERRM); END; /这个脚本跑通基本可以确认升级后的数据库能正常支撑业务。从那以后我每次升级完不管 DBUA 报告多漂亮都强制走一遍这个冒烟测试因为向导的成功和业务的可用之间有时候就差一个没编译过的存储过程。希望帮到你。本文还有配套的精品资源点击获取