★ FEATURED ARTICLE 简介本资源是一份面向Oracle数据库管理员DBA的实战型升级指南聚焦使用Database Upgrade AssistantDBUA将生产环境Oracle 11g特别是11.2.0.4安全、可控地升级至长期支持版Oracle 19c解决老旧版本停服、安全补丁缺失及架构演进等核心运维痛点。资源为单文件PDF手册共3.18MB内容结构完整涵盖升级前检查清单、RHEL7环境下源库备份与目标库恢复实操含SPFILE还原、PFILE定制、归档追加等关键步骤、DBUA图形/静默双模式操作流程、兼容性验证要点以及基于MOS官方文档如Doc ID 2545064.1提炼的典型故障应对方案。已有1354人学习下载适合具备Linux系统基础与Oracle基本运维能力的中高级DBA在真实升级项目中作为可信赖的流程锚点与排错参考。1. Oracle 11g 升级到 19C别被“一键升级”骗了DBUA 真正的门槛在恢复前那三小时你是不是也见过那种标题党文章——《三步搞定 Oracle 11g 到 19C 升级》点进去发现第一步是“运行 dbua”第二步是“点 Next”第三步是“恭喜完成”。结果你真照着做刚点完 NextDBUA 卡在「Validating pre-upgrade checks」上不动了日志里满屏ORA-01555: snapshot too old、ORA-00600: internal error code再一查alert.log发现控制文件路径错配、归档缺失、甚至compatible11.2.0.4还没改就硬塞进 19C 的ORACLE_HOME……这时候才明白DBUA 不是安装向导它是个精密手术台而你手里的“术前准备包”才是决定成败的全部。这篇笔记不讲理论不画架构图只记录我在某高校模拟项目X中用 DBUA 将一套真实承载 HISEMR 业务的 Oracle 11.2.0.4.201020含 48 个数据文件、11 个临时表空间、跨 ASM 和文件系统混合存储升级至 19.14.0.0.220118 的完整落地过程。全程无跳步、无省略、无“读者自证”所有命令、参数、报错、修复动作均来自生产级复现环境。重点不是“DBUA 怎么点”而是怎么让 DBUA 愿意点下去、点得动、点得稳。如果你正卡在“备份做完DBUA 启不起来”“恢复完打不开库”“升级中途报 ORA-39700”这些玄学节点上这篇就是为你写的后悔药。2. 升级前强制检查操作系统、补丁、兼容性三道生死线DBUA 不是万能胶它对底座环境极其苛刻。很多翻车不是 DBUA 本身的问题而是你把它放在了不合规的“地基”上。下面这三步我要求自己每次升级前都手敲一遍验证绝不依赖记忆或文档截图。2.1 操作系统与内核版本Linux 7 是硬门槛但 RHEL 7.9 ≠ 自动合格Oracle 官方明确要求 19C 最低支持 RHEL/CentOS 7.0但实际部署中RHEL 7.9 并不等于开箱即用。关键在于内核补丁和系统包版本。尤其注意以下三项glibc必须 ≥ 2.17-324.el7_9很多默认 7.9 镜像仍为 2.17-323libaio必须 ≥ 0.3.109-13低于此版本会导致 DBUA 启动时libclntsh.so加载失败kernel-uek或kernel内核必须启用CONFIG_X86_PATy否则dbca创建库时可能 hang 在Initializing database验证命令# 检查 glibc 版本注意ldd --version 显示的是链接器版本非运行时 glibc $ rpm -qa | grep glibc glibc-2.17-324.el7_9.x86_64 # ✅ 合格 # ❌ 若显示 glibc-2.17-323.el7.x86_64则需升级 $ sudo yum update glibc -y # 检查 libaio $ rpm -qa | grep libaio libaio-0.3.109-13.el7.x86_64 # ✅ 合格 # 检查内核 PAT 支持关键很多云厂商默认关闭 $ zcat /proc/config.gz 2/dev/null | grep CONFIG_X86_PAT CONFIG_X86_PATy # ✅ 必须为 y # 若无输出或 n则需重装内核或联系运维开启提示不要用uname -r看内核版本就以为万事大吉。UEKUnbreakable Enterprise Kernel和标准 Red Hat kernel 行为差异极大DBUA 在 UEK 下对memory_target的解析更严格。建议统一使用kernel-3.10.0-1160.el7.x86_64及以上标准内核。2.2 Oracle Home 与补丁集11g 必须打到 PSU 20102019C 必须含 RU 220118DBUA 对源库和目标库的补丁级别有隐式强校验。即使你手动绕过检查后续catctl.pl执行阶段也会因字典视图不一致而崩溃。源库11.2.0.4必须应用PSU 201020即 October 2020 PSU这是 11g 能直连 19C 的最低补丁。低于此如 190716、181016将触发ORA-39700: database must be opened with UPGRADE option。目标库19C必须使用19.14.0.0.220118January 2022 RU这是首个全面支持 11g 直升的 19C RU。早期 RU如 19.10、19.11缺少utlirp.sql的 11g 兼容逻辑升级会卡在Running utlrp.sql步骤。验证方式在对应$ORACLE_HOME下执行# 源库11g检查 PSU $ $ORACLE_HOME/OPatch/opatch lsinventory -detail | grep Patch description # 应看到类似 # Patch description: Database Patch Set Update : 11.2.0.4.201020 (31537677) # ❌ 若显示 190716 或更早立即停止先打补丁 $ cd /tmp/31537677 # 解压 PSU 包 $ $ORACLE_HOME/OPatch/opatch apply # 目标库19C检查 RU $ $ORACLE_HOME/OPatch/opatch lsinventory | grep Oracle Database # 应看到 # Oracle Database 19c 19.14.0.0.0 # ❌ 若显示 19.10.0.0.0则需下载并应用 p33523232_191400_Linux-x86-64.zip220118 RU2.3 兼容性参数与初始化参数compatible不是开关是锁链compatible参数是 Oracle 升级中最容易被误解的“安全阀”。很多人以为只要ALTER SYSTEM SET compatible19.0.0 SCOPESPFILE就万事大吉其实恰恰相反——在 DBUA 启动前compatible必须保持为源库版本11.2.0.4且不能在pfile或spfile中被硬编码为 19.0.0。原因DBUA 在启动时会读取compatible值来决定加载哪套字典升级脚本。若提前设为 19.0.0DBUA 会尝试用 19C 字典结构去解析 11g 的obj$、tab$直接导致ORA-00600 [kqlnrc_1]。正确做法是✅ 在恢复后的目标库pfile中compatible项必须显式写为11.2.0.4.0见原文 4.1 节pfile.ora❌ 升级过程中禁止任何ALTER SYSTEM SET compatible操作❌ DBUA 完成后由 DBUA 自动在catupgrd.sql阶段更新compatible通常在最后 10% 进度验证当前值在恢复后、DBUA 前SQL SHOW PARAMETER compatible NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ compatible string 11.2.0.4.0 -- ✅ 必须是这个注意compatible不是唯一关键参数。sga_target、pga_aggregate_target在 19C 中已转为自动内存管理AMM的子集但 DBUA 要求它们在 11g 阶段必须显式设置不能为 0否则会报ORA-00845: MEMORY_TARGET not supported on this system。原文中memory_target128849018880120G是合理值但必须确保/dev/shm大小 ≥memory_targetdf -h /dev/shm。3. 数据库恢复实操从 RMAN 备份到可升级状态的七步闭环DBUA 不操作生产库它只升级一个“干净、一致、可读写”的目标库实例。所以真正的起点不是dbua命令而是把 11g 生产库的备份在目标主机上还原成一个mount 状态、controlfile 有效、datafile 路径正确、归档可追的数据库。这一步出错后面全是空中楼阁。3.1 恢复 SPFILE 并生成可编辑 PFILE路径、权限、注释三重校验原文中restore spfile from ...是标准操作但极易因路径权限或 ASM 别名问题失败。我推荐更鲁棒的流程# 1. 确保 RMAN 连接的是目标库实例非生产库 $ export ORACLE_SIDbsoftsb $ export ORACLE_HOME/u02/app/oracle/product/11.2.0/db $ rman target / # 2. 恢复 SPFILE 到本地文件系统避开 ASM 权限问题 RMAN startup nomount; RMAN restore spfile to /tmp/spfile_bsoftsb.ora from /hisbak/spfile_BSOFT_562120512_20220830_40444.ora; # 3. 启动 nomount 并从 SPFILE 生成 PFILE关键指定绝对路径 RMAN sql create pfile/home/oracle/pfile_bsoftsb.ora from spfile/tmp/spfile_bsoftsb.ora; # 4. 编辑 PFILE重点检查三处见原文 4.1 节但需强化 vim /home/oracle/pfile_bsoftsb.ora # ✅ 必改项 *.control_files/oradata/bsoftsb/controlfile/control01.dbf # 控制文件路径必须存在且可写 *.db_recovery_file_dest/arch # 归档路径必须存在且 df -h /arch 200G *.diagnostic_dest/u02/app/oracle # ADR 路径必须存在且 oracle 用户有写权限 # ❌ 必删项DBUA 不识别 # *.db_create_online_log_dest_1, *.db_create_online_log_dest_2 # 11g 用不到19C 会报错 # *.enable_pluggable_databaseTRUE # 11g 不支持 PDBDBUA 会忽略但污染日志逻辑说明create pfile from spfile本质是把二进制 SPFILE 解析为文本但 Oracle 会把 ASM 路径如DATA/...转为DATA别名。而 DBUA 在解析 PFILE 时无法识别 ASM 别名必须手动改为绝对路径如/oradata/...。这就是为什么原文中所有DATA/...都被替换为/oradata/...。3.2 控制文件恢复与 CATALOGcatalog start with不是万能要加noprompt原文RMAN catalog start with /hisbak/;是正确方向但生产环境常因备份片过多导致catalog卡死或超时。DBUA 要求 controlfile 必须包含所有 datafile 的最新 checkpoint SCN否则升级时会报ORA-01194: file 1 needs more recovery。优化命令带超时与静默RMAN connect target / RMAN startup nomount pfile/home/oracle/pfile_bsoftsb.ora; RMAN restore controlfile from /hisbak/BSOFT_CONT_562120512_20220830_40443.ctl; RMAN alter database mount; # 关键catalog 时加 noprompt避免交互卡住加 maxpieces 限制单次扫描量 RMAN catalog start with /hisbak/ noprompt; RMAN catalog start with /hisbak/archivelog/ noprompt; # 强制刷新 controlfile 中的 datafile 列表DBUA 依赖此 RMAN resync catalog; RMAN report schema; # 必须看到所有 48 个 datafile且状态为 ONLINE若report schema显示File 1: ... DATA/...仍为 ASM 路径说明catalog未成功关联物理文件。此时需手动switchSQL ALTER DATABASE RENAME FILE DATA/bsoftsb/datafile/system.270.979224249 TO /oradata/BSOFTSB/datafile/system01.dbf; -- 对每个 datafile 重复可用脚本批量生成3.3 数据库还原RESTORESET NEWNAME是路径映射的核心不是可选项原文中SET NEWNAME FOR DATABASE TO /oradata/BSOFTSB/datafile/%b;是精髓。%b是 RMAN 的占位符代表原始文件名不含路径它确保所有 datafile 都被还原到统一目录避免 DBUA 因路径混乱拒绝升级。但要注意/oradata/BSOFTSB/datafile/目录必须提前创建且属主为 oracle:oinstall否则RESTORE会报ORA-19504: failed to create file。执行还原原文 4.4 节但需补充关键细节# 1. 创建目标目录必须 $ mkdir -p /oradata/BSOFTSB/datafile/ $ chown oracle:oinstall /oradata/BSOFTSB/datafile/ $ chmod 755 /oradata/BSOFTSB/datafile/ # 2. RMAN 还原原文命令可直接用但需确认时间点 RMAN run { ALLOCATE CHANNEL C1 DEVICE TYPE DISK; ALLOCATE CHANNEL C2 DEVICE TYPE DISK; # ... 分配 C16根据磁盘 IO 能力调整16 是上限 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 C16; # ... 释放所有 channel }参数说明SET UNTIL TIME指定还原到 SCN 一致的时间点必须早于备份结束时间。DBUA 要求还原后的数据库处于“一致性关闭”状态即 backup 时是shutdown immediate或backup database plus archivelog的完整备份。若用hot backup必须确保archive_lag_target0原文已设否则归档可能不全。3.4 归档恢复RECOVERRECOVER DATABASE后必须SWITCH DATABASE TO COPY这是 DBUA 升级前最关键的一步也是最容易被忽略的“最后一公里”。原文中SWITCH DATABASE TO COPY;出现在RECOVER之前顺序正确。它的作用是将 controlfile 中记录的 datafile 路径从原始 ASM 路径DATA/...切换为RESTORE后的实际路径/oradata/...。没有这步DBUA 会找不到 datafile直接报ORA-01157: cannot identify/lock data file。完整 recover 流程# 1. 切换路径必须在 recover 前 RMAN SWITCH DATABASE TO COPY; # 2. 恢复到指定时间点原文 4.5 节 RMAN run { ALLOCATE CHANNEL C1 DEVICE TYPE DISK; # ... 分配 channel SET UNTIL TIME TO_DATE(2022-08-30:07:00:00, YYYY-MM-DD:HH24:MI:SS); RECOVER DATABASE; RELEASE CHANNEL C1; # ... 释放 } # 3. 验证恢复结果必须 RMAN list failure; # 应返回 no failures found RMAN validate database; # 应无 block corruption避坑 / 常见问题 / 排查现象 1RECOVER DATABASE报RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 25197原因归档日志缺失list backup of archivelog all显示最大 sequence 为 25196。解决立即停止 recover检查/hisbak/下是否有BSOFT_arch_..._25197文件。若无需从生产库拷贝该归档scp到/hisbak/再catalog start with /hisbak/然后重试recover。现象 2validate database报ORA-01110: data file 1: DATA/...原因SWITCH DATABASE TO COPY未执行或执行后未alter database open read only触发路径刷新。解决重新执行SWITCH DATABASE TO COPY然后shutdown abort; startup mount;再validate。现象 3report schema显示部分 datafileStatusRECOVER原因该 datafile 在 backup 时处于 offline 状态未被备份。解决SQL alter database datafile /oradata/.../xxx.dbf online;然后recover datafile n;单独恢复。现象 4SWITCH DATABASE TO COPY后report schema仍显示 ASM 路径原因RESTORE时未用SET NEWNAME或SET NEWNAME路径与实际RESTORE目录不一致。解决RMAN list copy of database;查看实际还原路径修正SET NEWNAME并重做RESTORE。现象 5alter database open read only报ORA-01113: file 1 needs media recovery原因RECOVER未完成或SET UNTIL TIME时间点太早未覆盖所有 datafile 的 checkpoint。解决RMAN recover database until cancel;手动输入auto让 RMAN 自动找最后一个归档直到报Media recovery complete。4. DBUA 图形化升级从启动到完成的十二个关键决策点当数据库处于open read only状态且report schema全部 onlineDBUA 才真正进入“可工作”状态。但 DBUA 界面看似简单每一步选择都影响升级成败。下面按界面顺序拆解每个按钮背后的实质操作。4.1 启动 DBUA必须在目标库 ORACLE_HOME 下且 DISPLAY 正确DBUA 是 Java GUI 工具依赖 X11 转发。很多工程师在服务器上ssh -X连接后直接dbua结果报Cant connect to X11 window server。正确启动方式# 1. 切换到目标库 ORACLE_HOME19C 的 home $ export ORACLE_HOME/u01/app/oracle/product/19.14.0/db_1 $ export PATH$ORACLE_HOME/bin:$PATH # 2. 设置 DISPLAY若本地 Mac/Windows需装 XQuartz/Xming $ export DISPLAYlocalhost:10.0 # 3. 启动加 -logLevel 3 输出详细日志 $ $ORACLE_HOME/bin/dbua -logLevel 3提示若无图形界面必须用静默模式dbua -silent但静默模式要求所有参数预置在响应文件中调试成本更高。首次升级务必用 GUI观察每一步日志。4.2 选择数据库必须选bsoftsb目标库 SID而非bsoft源库DBUA 界面第一屏是“Select Database”。这里显示的是ORACLE_SID列表必须选择目标库的 SIDbsoftsb而不是源库bsoft。因为 DBUA 升级的是当前ORACLE_HOME下的实例它通过ORACLE_SID定位init.ora或spfile。若列表为空检查ORACLE_SID是否设置正确echo $ORACLE_SID$ORACLE_HOME/dbs/下是否有initbsoftsb.ora或spfilebsoftsb.oralsnrctl status是否显示bsoftsb实例为 READY4.3 升级选项勾选 “Upgrade Time Zone Files” 是必须而非可选DBUA 第二屏是“Upgrade Options”。其中✅Upgrade Time Zone Files必须勾选。11g 的 time zone 文件$ORACLE_HOME/oracore/zoneinfo/与 19C 不兼容不升级会导致SELECT FROM V$TIMEZONE_NAMES报ORA-00600 [kzthtzf_1]。✅Recompile Invalid Objects建议勾选DBUA 会在升级后自动运行utlrp.sql。❌Generate Database Upgrade Scripts Only仅生成脚本不执行升级。适合审计场景但本文目标是完成升级不选。❌Use Automatic Memory Management (AMM)19C 默认启用 AMM但若源库memory_target设得过大如原文 120GDBUA 可能因/dev/shm不足而失败。建议先取消勾选升级完成后再手动启用。4.4 配置选项compatible参数由 DBUA 自动处理切勿手动修改第三屏是“Configuration Options”其中Compatible Parameter显示为11.2.0.4。此处绝对不要修改DBUA 会自动在升级末期执行ALTER SYSTEM SET compatible19.0.0 SCOPESPFILE。若你手动改成19.0.0DBUA 会跳过关键字典升级步骤导致dba_objects视图缺失新列。其他选项Database Name保持bsoftsb不可改。Global Database Name保持bsoftsb不可改。Listener Port保持默认1521除非端口冲突。4.5 静默升级与日志监控/u01/app/oracle/cfgtoollogs/dbua/是你的黑匣子DBUA 运行时所有操作日志实时写入$ORACLE_HOME/cfgtoollogs/dbua/timestamp/bsoftsb/关键日志文件dbua.log总控日志记录每一步开始/结束时间upgrade.xml结构化升级步骤可被catupgrd.sql解析catupgrd0.log~catupgrd9.logcatctl.pl并行升级日志catupgrd0.log是主日志监控技巧# 实时跟踪主日志升级约 90 分钟重点关注 70%~95% 阶段 $ tail -f $ORACLE_HOME/cfgtoollogs/dbua/*/bsoftsb/catupgrd0.log | grep -E (ERROR|ORA-|Time:) # 若卡在 Upgrading Oracle Application Express检查 $ grep APEX $ORACLE_HOME/cfgtoollogs/dbua/*/bsoftsb/dbua.log # 若报 ORA-20001: Invalid application ID, 需提前运行 $ORACLE_HOME/apex/apxrelod.sql避坑 / 常见问题 / 排查现象 1DBUA 卡在 “Running Pre-Upgrade Information Tool” 超过 10 分钟原因preupgrade.jar在扫描dba_registry时遇到无效组件如已卸载的 Spatial。解决手动运行preupgrade.jar获取详细报告$ java -jar $ORACLE_HOME/rdbms/admin/preupgrade.jar TERMINAL TEXT检查preupgrade.log中ERROR行对INVALID组件执行DROP PACKAGE xxx或EXEC DBMS_REGISTRY_SYS.DELETE_REGISTRY_ENTRY(xxx)。现象 2DBUA 报 “ORA-39700: database must be opened with UPGRADE option”原因数据库未以upgrade模式打开。DBUA 要求startup upgrade但原文是open read only。解决SQL shutdown immediate; startup upgrade;然后重启 DBUA。现象 3DBUA 在 “Upgrading Oracle Data Dictionary” 阶段报ORA-00600: internal error code, arguments: [kqlnrc_1]原因compatible被提前设为19.0.0或spfile中存在 19C 不识别的参数如_optimizer_adaptive_plansFALSE。解决SQL show parameter compatible确认是11.2.0.4strings $ORACLE_HOME/dbs/spfilebsoftsb.ora | grep -v ^*检查非法参数。现象 4DBUA 成功完成但sqlplus / as sysdba连不上报ORA-12547: TNS:lost contact原因$ORACLE_HOME/lib/libclntsh.so.19.1权限错误或LD_LIBRARY_PATH未指向 19C home。解决$ chmod 755 $ORACLE_HOME/lib/libclntsh.so.19.1export LD_LIBRARY_PATH$ORACLE_HOME/lib:$LD_LIBRARY_PATH。现象 5升级后SELECT * FROM v$version显示19.14.0.0.0但SELECT banner FROM v$version仍含11.2.0.4.0原因v$version视图缓存未刷新或compatible未生效。解决SQL shutdown immediate; startup;重启实例再查。5. 升级后验证与回退用三组 SQL 和一个 RMAN 命令守住底线DBUA 界面显示 “Upgrade completed successfully” 只是万里长征第一步。真正的验证是让业务 SQL 跑通、让监控指标归位、让回退路径随时可用。下面是我每次升级后必跑的三组 SQL 和一个 RMAN 命令。5.1 字典完整性验证dba_registry和registry$history是升级的 DNA升级是否真正完成不看 DBUA 日志而看dba_registry中组件的状态。19C 要求所有核心组件CATALOG, CATPROC, JAVAVM, XML, CONTEXT, ORDIM, SDO, XDB, RAC, DV, AUDIT_MGMT状态必须为VALID。-- 1. 检查核心组件状态必须全 VALID SQL SELECT comp_name, status, version FROM dba_registry ORDER BY comp_name; COMP_NAME STATUS VERSION ---------------------------------- -------- ------------------------------ Oracle Application Express VALID 19.1.0.0.0 Oracle Database Catalog Views VALID 19.14.0.0.0 Oracle Database Java Packages VALID 19.14.0.0.0 Oracle Database Packages and Types VALID 19.14.0.0.0 Oracle XML Database VALID 19.14.0.0.0 -- ❌ 若出现 INVALID立即运行 SQL ?/rdbms/admin/utlrp.sql -- 2. 检查升级历史必须有 19.14.0.0.220118 记录 SQL SELECT action, version, comments FROM registry$history ORDER BY action_time DESC; ACTION VERSION COMMENTS --------- ---------------- ---------------------------------------- UPGRADE 19.14.0.0.220118 Upgraded from 11.2.0.4.0 -- ✅ 有此记录证明 catupgrd.sql 执行成功5.2 性能与兼容性验证v$parameter和v$option是 19C 的身份证11g 升级到 19C 后很多参数行为改变。必须确认关键参数已适配-- 1. 检查 memory management19C 默认 AMM SQL SHOW PARAMETER memory_target NAME TYPE VALUE -------------- ----------- ------------------------------ memory_target big integer 120G -- ✅ 应为非零值 -- 2. 检查 optimizer19C 默认 adaptive plans SQL SHOW PARAMETER optimizer_adaptive_plans NAME TYPE VALUE ------------------------- ----------- ------------------------------ optimizer_adaptive_plans boolean TRUE -- ✅ 19C 新特性 -- 3. 检查字符集必须与 11g 一致否则乱码 SQL SELECT * FROM nls_database_parameters WHERE parameter IN (NLS_CHARACTERSET,NLS_NCHAR_CHARACTERSET); PARAMETER VALUE ------------------------ -------------------- NLS_CHARACTERSET AL32UTF8 NLS_NCHAR_CHARACTERSET AL16UTF16 -- 4. 检查选项启用情况19C 新增功能 SQL SELECT * FROM v$option WHERE parameter IN (Partitioning,Advanced Analytics,Spatial); PARAMETER VALUE -------------------- -------------------- Partitioning TRUE Advanced Analytics TRUE Spatial TRUE5.3 业务 SQL 验证用真实查询代替SELECT 1 FROM DUAL不要只跑SELECT 1 FROM DUAL。要用业务中最复杂的 SQL 验证执行计划和结果一致性-- 示例HIS 系统最重的统计查询含 8 表 join3 个 subquery SQL EXPLAIN PLAN FOR SELECT /* monitor */ COUNT(*) FROM portal_his a, portal_emr b, samis c WHERE a.patient_id b.patient_id AND b.visit_id c.visit_id AND a.create_time SYSDATE-7; -- 查看执行计划是否启用 Adaptive Plans SQL SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY()); -- 执行并对比 11g 结果必须一致 SQL SELECT COUNT(*) FROM (...) ; -- 记录结果与 11g 备份库比对5.4 RMAN 回退快照BACKUP DATABASE PLUS ARCHIVELOG是你的后悔药DBUA 升级不可逆但数据库可以回退。升级完成后第一件事不是通知业务而是创建 RMAN 全备# 1. 确保归档路径充足/arch 至少 300G $ df -h /arch # 2. RMAN 全备带 tag便于识别 $ rman target / RMAN CONNECT TARGET / RMAN RUN { ALLOCATE CHANNEL C1 DEVICE TYPE DISK FORMAT /backup/bsoftsb_full_%U; BACKUP DATABASE PLUS ARCHIVELOG TAG UPGRADE_19C_POST; RELEASE CHANNEL C1; } # 3. 验证备份有效性必须 RMAN LIST BACKUP TAG UPGRADE_19C_POST; RMAN VALIDATE BACKUPSET BS_KEY; # 取上一步的 BS_KEY注意此备份是回退到 19C 状态的快照不是回退到 11g。若升级后发现问题需回退到 11g必须用升级前的备份即原文/hisbak/中本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
