简介面向具备一定运维能力的数据库管理员这份 Oracle 11g 升级至 19C 的实务手册围绕 DBUA 工具展开重点解决生产库迁移中的版本兼容、备份恢复与升级风险控制问题。全包仅 1 个 PDF 文件约 3.18MB篇幅集中、便于随查随用。内容覆盖前期 RMAN 备份与异机恢复、DBUA 图形化及静默升级流程、必要参数调整并提醒逐项核对检查脚本输出的日志与警告同时给出 MOS 参考文档、直升级与间接升级路线、操作系统版本要求及多种异常处置思路。已有 1360 人学习适合希望安全完成 11g 到 19C 迁移、提升性能与安全合规性的运维人员对照实践和排错复盘。1. 从 11.2.0.4 到 19.14先判断这条路能不能一步走完凌晨收到一条通知一套还在跑 11.2.0.4 的单机库不再有补丁而新机器上 19.14 的软件已经装好。Oracle 11g 到 19C 的升级用 DBUA 点几下确实能走完真正卡住人的从来不是向导界面而是点之前的三件事源库版本能不能直连 19C、主机是不是 Linux 7 以上、备份能不能在升级机上按时间点恢复出来。这份手册记录的是走通过的一条路径——生产库先用 RMAN 恢复到独立主机只读验证无误后交给 DBUA 原地升级源库原封不动留作回退。适合能进 SYSDBA、会写 RMAN 脚本、准备把老库迁到 19C 的运维也适合想弄清 DBUA 每一步到底改了什么的人。2. 升级前的硬性门槛升级路线、主机版本与源库体检2.1 先判路线直连还是中转11g 到 19C 不是所有小版本都能一步到位这个判断做错了后面所有准备工作都是白费。DBUA 在执行前的 precheck 阶段会直接读源库的v$instance和dba_registry版本不在直连清单里就会拒绝继续不会给你“强行升级”的选项。源库版本到 19C 的路径说明11.2.0.4 及以上直接升级主流路径DBUA 直接支持11.2.0.1 / 11.2.0.2 / 11.2.0.3先补到 11.2.0.4再升 19C差一个补丁集必须先打11.1.0.6 / 11.1.0.7先到 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.112.1.0.1 不在直连清单12.1.0.2 / 12.2.0.1 / 18c直接升级与 11.2.0.4 同路径表里最容易误判的是 11.2.0.1 到 11.2.0.3。很多环境自报“11.2.0.4”实际opatch lspatches里只有 PSU 没有基版升级v$instance.version还是 11.2.0.3。判断依据统一看select version, version_full from v$instance;别看安装介质的目录名。2.2 主机版本Linux 6 上的库必须换机19C 对操作系统的最低要求是 Linux 7RHEL 或同源发行版 7 及以上。11g 时代大量库跑在 RHEL 6 上19C 的安装介质在那上面根本装不起来这不是打补丁能解决的。先cat /etc/redhat-release看主版本号是 6 就老老实实准备新机器别在原地耗时间。原地升级只在一种情况下成立源库主机已经是 7 以上并且同一台机器上可以并存两套 ORACLE_HOME。这种情况下升级的本质是“换 home 启动”不是“换机器”环境变量的隔离就成了头号问题。ORACLE_HOME、ORACLE_BASE、PATH、LD_LIBRARY_PATH一次只能指向一套切 home 靠source不同的 profile 文件不要靠临时 export 拼凑否则 DBUA 会读到错误的oratab和错误的dbua可执行文件。两套 home 并存还要处理监听。19C 的监听用 19C home 下的lsnrctl启动11g 的监听在升级窗口内停掉/etc/oratab里两个 SID 的条目都要保留DBUA 依靠它识别源库版本。端口不要复用11g 监听占 152119C 监听可以先用 1522升级完成后再切回避免升级期间应用误连到正在被 DBUA 重启的实例。2.3 用 preupgrade 脚本把源库的雷提前排掉DBUA 自带 precheck但它只告诉你“不行”不告诉你“怎么修”。真正干活的是 preupgrade 脚本它会在源库上做一次全面体检并生成可以自动修复的 SQL 脚本。# 在源库所在主机执行preupgrade.jar 从 19C 的 $ORACLE_HOME/rdbms/admin 目录拷贝过来 export ORACLE_SIDPRODDB export ORACLE_HOME/u01/app/oracle/product/11.2.0/dbhome_1 export PATH$ORACLE_HOME/bin:$PATH # 11.2.0.4 自带 jdk 1.6/1.7能直接跑 jar $ORACLE_HOME/jdk/bin/java -version # TERMINAL 输出到终端TEXT 生成文本报告而不是 HTML mkdir -p /home/oracle/preupgrade cd /home/oracle/preupgrade $ORACLE_HOME/jdk/bin/java -jar /home/oracle/preupgrade.jar \ TERMINAL TEXT \ /home/oracle/preupgrade/preupgrade_stdout.log 21这段命令的逻辑很直接用源库自己的 JDK 跑 19C 提供的检查包避免 Java 版本不兼容导致脚本静默失败。TERMINAL TEXT两个参数分别控制输出目标和格式只写TERMINAL会走交互式终端只写TEXT会生成文件但不在屏幕提示两个一起写才是“屏幕看得见 文件留得下”。执行完之后产物在$ORACLE_BASE/cfgtoollogs/sid/preupgrade/下一共三个文件preupgrade.log是体检报告preupgrade_fixups.sql要在源库上执行postupgrade_fixups.sql留到升级之后。体检报告要用眼睛过一遍不能只看最后一行“建议升级”。几个必须自己复核的项-- 组件状态任何一行不是 VALID 都要先处理DBUA 会因此拒绝升级 SELECT comp_id, comp_name, version, status FROM dba_registry ORDER BY comp_id; -- 时区文件版本19C 常见需要 DSTv32 SELECT version FROM v$timezone_file; -- 无效对象升级前应该接近 0 SELECT owner, object_type, COUNT(*) FROM dba_objects WHERE status INVALID GROUP BY owner, object_type ORDER BY 3 DESC; -- 只读表空间和脱机数据文件升级期间无法处理 SELECT tablespace_name, status FROM dba_tablespaces WHERE status ONLINE; SELECT file#, name, status FROM v$datafile WHERE status ONLINE; -- 字符集跨字符集升级不属于 DBUA 的范畴 SELECT parameter, value FROM nls_database_parameters WHERE parameter IN (NLS_CHARACTERSET,NLS_NCHAR_CHARACTERSET);dba_registry里status不是VALID是 precheck 最常见的拦路虎XDB、OLS、JVM 这三个在 11g 上尤其容易留下半死不活的状态。处理原则是“卸载重装”而不是“手工改状态”XDB 用?/rdbms/admin/catnoqm.sql卸载后catqm.sql重装JVM 用catnojav.sql加catjava.sql。这些脚本会动数据字典只在已经恢复出来的升级库上跑不要碰生产。只读表空间这一项经常被忽略。DBUA 升级时会尝试写字典和部分组件表遇到只读表空间直接报错中断alter tablespace ... read write之后记得在升级完成后改回去。2.4 目标端 19C 软件安装的三个细节19C 软件用 OUI 装选 “Install software only”不要顺手建库否则会多出一个空实例干扰oratab判断。第一个细节是用户组。oracle用户的主组必须是oinstall附加组至少包含dba、oper和 11g 侧完全一致。组不一致会导致 DBUA 切换 home 时权限不足报一堆ORA-01031。第二个细节是系统参数。19C 对nofile的要求比 11g 高/etc/security/limits.conf里至少给到 65536kernel.shmmax、kernel.shmmni、fs.aio-max-nr按 19C 的安装文档重新算不要沿用 11g 机器上那份几年前的值。半导体现在很常见/dev/shm太小会让memory_target启动直接失败。第三个细节是oraInst.loc。装完 19C 跑root.sh时如果机器上已经有 11g 的/etc/oraInst.loc让它保持指向同一个 inventory 目录不要被覆盖成新路径否则opatch会找不到两套 home 的补丁信息。3. 用 RMAN 把生产库搬到升级机恢复链路怎么搭3.1 参数文件从 spfile 到 pfile 的路径重写升级不在生产机上做这是整条路径的核心决策。生产库保持原样把备份恢复到一台装了 11g 和 19C 两套软件的升级机上在升级机上用 11g home 把库拉起来只读验证后再交给 DBUA。这样任何一步翻车最坏结果只是升级机重来生产库连重启都不需要。恢复的第一步是把参数文件从备份里捞出来# 升级机上先切到 11g 环境恢复动作全部由 11g home 完成 export ORACLE_SIDPRODDB export ORACLE_HOME/u02/app/oracle/product/11.2.0/dbhome_1 export PATH$ORACLE_HOME/bin:$PATH rman target /RMAN startup nomount; RMAN restore spfile from /hisbak/spfile_PRODDB_20220830_40444.ora; RMAN exit; -- 用还原出来的 spfile 生成可编辑的 pfile SQL create pfile/home/oracle/pfile.ora from spfile;startup nomount只需要参数文件就能起实例所以这一步能在数据文件还没到位时先做。restore spfile from后面跟的是备份片路径不是备份集编号路径写错会报RMAN-06026先用ls -l确认文件存在。生成的 pfile 必须逐项改成本机路径不能直接拿来启动# /home/oracle/pfile.ora 关键改动项其余保持源库原值 *.audit_file_dest/u02/app/oracle/admin/proddb/adump *.control_files/oradata/proddb/controlfile/control01.ctl *.db_create_file_dest/oradata *.db_recovery_file_dest/arch *.db_recovery_file_dest_size200G *.db_unique_namePRODDB_UPG *.diagnostic_dest/u02/app/oracle *.log_archive_dest_1LOCATIONuse_db_recovery_file_dest VALID_FOR(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAMEPRODDB_UPG *.log_archive_format%t_%s_%r.dbf *.memory_target64G *.sga_target32G *.pga_aggregate_target8G *.processes6000 *.sessions3305db_unique_name必须和源库不同否则归档命名和后续的 Data Guard 配置会撞车db_name保持原值不动DBUA 认的是db_name。内存三项是异地恢复最容易翻车的地方源库 128G 的memory_target原样搬到 64G 的机器上实例连 nomount 都过不去报ORA-00845或直接 OOM。先按目标机物理内存的 60% 给起来之后再调。改完之后SQL startup nomount pfile/home/oracle/pfile.ora; SQL create spfile from pfile/home/oracle/pfile.ora; SQL shutdown immediate; SQL startup nomount;先 pfile 起、再固化 spfile、再重启目的是让实例从默认的$ORACLE_HOME/dbs读 spfile后面 DBUA 切 home 时不会因为找不到参数文件而失败。3.2 控制文件、catalog 与数据文件重定位参数文件就位后控制文件是下一个关键入口。控制文件里记录了所有数据文件的绝对路径这些路径在新机器上大概率不存在所以顺序必须是“先还原控制文件 → mount → 加载备份 → 重定位 → 还原数据文件”。RMAN restore controlfile from /hisbak/PRODDB_CONT_20220830_40443.ctl; RMAN sql alter database mount; RMAN catalog start with /hisbak/; RMAN report schema;restore controlfile会自动把实例从 nomount 推进到 mount不需要手动再 mount 一次多写一条alter database mount会报ORA-01081。catalog start with把备份目录下所有备份片注册进控制文件备份目录大、片子多的时候这一步会跑十几分钟可以先用catalog start with /hisbak/arch/分批加载。report schema的输出是重定位的依据。如果源库用的是 ASM看到的全是DATA/...这种路径在新机器上必须全部替换RMAN 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; -- %b 保留原文件名统一重定位到新目录 set newname for database to /oradata/proddb/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; }通道数按目标机 CPU 和存储带宽定4 到 8 个是常见区间开太多会因为 IO 争抢反而更慢。%b只保留文件名不保留原目录如果不同表空间下有同名文件两个system01.dbf这种情况restore会互相覆盖这时改用%U生成唯一名或者在set newname里按 datafile 号逐个指定。set until time给了一个不完整恢复的时间点这是有意为之——先把库拉到一个较早的、确定一致的时点验证没问题之后再拿归档往前追。追不追、追到哪儿主动权在自己手上。还原完成后必须执行一次路径切换RMAN switch database to copy;这条命令把控制文件里记录的数据文件路径真正改写成set newname指定的新路径。少这一步后面的recover会去源库的老路径找文件报ORA-01189或ORA-01119。3.3 只读打开与追归档把恢复时间点往前推第一轮恢复之后库还不能直接给 DBUA。先recover到一个业务低峰时点再只读打开做数据校验RMAN 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; }recover完成后再打开SQL alter database open read only; SQL select count(*) from v$datafile; SQL select file#, checkpoint_change# from v$datafile_header; SQL select count(*) from 业务核心表;只读打开的目的是让业务方连上来核对数据读数对不上说明恢复链路有问题这时候停下来查归档比升级完再查便宜得多。只读状态下库不能被 recover想继续往前追必须先关掉SQL shutdown abort; SQL startup mount;然后从源库把新产生的归档拷过来重新 catalog 再 recover# 源库侧持续拷贝归档rsync 只传增量 rsync -avz /arch/ PRODDB10.10.10.21:/hisbak/arch/RMAN catalog start with /hisbak/arch/; RMAN run { allocate channel c1 device type disk; allocate channel c2 device type disk; set until time to_date(2022-08-30:12:00:00,yyyy-mm-dd:hh24:mi:ss); recover database; release channel c1; release channel c2; }不指定until time时 RMAN 会一直追到归档尽头然后报RMAN-06054: media recovery requesting unknown archived log。这个报错不是失败它只是在说“归档不够了”属于预期行为看到它就可以停手。真正的失败是RMAN-06054之前出现ORA-开头的错误那才需要查。追到哪个时间点停我一般追到源库业务停写、进入维护窗口的那一刻为止把它作为最终恢复点。这样升级完成后切换过去丢失的数据窗口就是维护窗口本身业务方容易接受。4. DBUA 实操从 precheck 到 postupgrade4.1 升级前最后一公里的准备库恢复好、只读验证通过之后把它切成可读写但不接业务的状态这是 DBUA 的起点。/etc/oratab里这个 SID 的 home 必须还指向 11gDBUA 依靠它判断“源库是 11.2.0.4目标 home 是 19C”。如果之前手工改成了 19CDBUA 会认为没有可升级的源库列表里空空如也。口令文件要提前处理。19C 从 12c 起换了口令文件格式11g 的orapwPRODDB在 19C 下能读但哈希算法不一致远程 sysdba 登录会遇到ORA-01017。做法是在升级前用 19C 的orapwd重建一次export ORACLE_HOME/u01/app/oracle/product/19.14.0/dbhome_1 # format12 生成 12c 及以上格式19C 必须用这个entries 给 sys/system 和几个 dba 账户留位置 $ORACLE_HOME/bin/orapwd file$ORACLE_HOME/dbs/orapwPRODDB \ passwordsys密码 entries10 format12此时实例还在用 11g home 运行往 19C home 的dbs目录写口令文件不影响它DBUA 切换 home 后正好用上。这一步提前做掉能省掉升级完成后一半的登录类报错。启动 DBUA 之前的环境变量要一次性设置正确export ORACLE_SIDPRODDB export ORACLE_HOME/u01/app/oracle/product/19.14.0/dbhome_1 export ORACLE_BASE/u01/app/or p a hrefhttps://download.csdn.net/download/u010575833/89885829 stylecolor:#ec7500;font-size:14px; 本文还有配套的精品资源点击获取 /a img altmenu-r.4af5f7ec.gif srchttps://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif stylewidth:16px;margin-left:4px;vertical-align:text-bottom;cursor:text; /p