简介本资源是一份面向Oracle数据库管理员DBA的实战型升级指南聚焦使用Database Upgrade AssistantDBUA将生产环境中的Oracle 11g特别是11.2.0.4安全、可控地升级至长期支持版Oracle 19c解决老旧版本停服、安全补丁缺失及架构演进等核心运维痛点。资源为单文件PDF手册共3.18MB内容结构严谨覆盖升级前检查清单、RHEL7环境下源库备份与目标库恢复实操含SPFILE还原、PFILE定制、归档追加等关键步骤、DBUA图形/静默双模式操作流程、兼容性约束如Linux6需迁移主机、直接与间接升级路径对照以及十余类典型故障的定位与回退方案。预览显示其深度整合Oracle官方MOS文档如Doc ID 2545064.1并附有真实测试环境参数配置与注意事项提示强调日志分析与顺序执行。目前已有1354人学习下载适合具备基础Oracle运维能力、正推进数据库现代化升级的中高级DBA快速落地实施。1. Oracle 11g 升级到 19C别被“直接支持”骗了11.2.0.4 是生死线Linux 7 是硬门槛你手头那套跑着 Oracle 11g 的生产库大概率是 11.2.0.3 或更早——但 Oracle 官方文档里白纸黑字写的 “Direct Upgrade to 19.x: 11.2.0.4 and Higher”不是鼓励你冲是在划红线。我见过太多 DBA 拿着 11.2.0.3 的库点开 DBUA界面刚加载完就弹出PRVG-0010 : The minimum required version of the operating system is not satisfied再一看/etc/redhat-release是 RHEL6.9瞬间头皮发麻。这不是配置问题是地基没打牢19C 要求最低 Linux 7 内核3.10而 11g 时代大量生产环境还卡在 2.6.32更致命的是11.2.0.1/2/3 这三个版本压根不被 DBUA 接受强行启动会卡在 Pre-Upgrade Checks 阶段报ORA-00600: internal error code, arguments: [kcrf_update_ckpt]这类玄学错误日志里翻不出根源。本文讲的不是理论路径而是真实踩过坑、回滚过三次、最终在 RHEL7.9 11.2.0.4.201020PSU Oct 2020上跑通的 DBUA 升级全链路——从备份恢复的 RMAN 命令细节到 DBUA 静默模式参数怎么写才不丢-ignoreSysPrereqs再到升级后utlrp.sql编译失败时该查哪张数据字典表。适合正在写升级方案的 DBA、被领导催着交割期的运维负责人以及想把测试环境搭成和生产一模一样的同学。这不是一次安装是一次带 rollback plan 的手术。2. 环境准备与前置检查操作系统、补丁、空间三道闸门必须全开Oracle 升级最反直觉的一点DBUA 不是万能钥匙它只负责“执行升级”不负责“创造条件”。很多翻车现场80% 的问题出在 DBUA 启动前——你以为在装数据库其实是在搭舞台。2.1 操作系统与内核版本RHEL7.9 是甜点但得确认 kernel 实际版本DBUA 对 OS 的校验不是看/etc/redhat-release而是读/proc/sys/kernel/osrelease。RHEL7.9 默认 kernel 是 3.10.0-1160但如果你手动升级过 kernel比如装了 4.18DBUA 反而可能报错PRVG-0011 : The operating system version is not supported因为 Oracle 19C 认证列表里只写了 “RHEL7.6–7.9”没写 kernel 4.x。所以第一步不是装软件是锁版本# 查看真实内核版本注意不是 uname -r 的简写 cat /proc/sys/kernel/osrelease # 输出应为类似3.10.0-1160.el7.x86_64 # 如果是 4.x需回退到认证内核RHEL7.9 默认内核包名 rpm -qa | grep kernel-3.10 # 安装并设为默认启动项以 3.10.0-1160 为例 grubby --set-default /boot/vmlinuz-3.10.0-1160.el7.x86_64 reboot提示DBUA 启动时会调用$ORACLE_HOME/bin/rvuReal Application Testing Validation Utility做 OS 检查其校验逻辑硬编码在$ORACLE_HOME/rdbms/admin/rvu_os_check.sql里不建议修改。老老实实按 MOS 文档 Doc ID 2545064.1 的 Table 1 对照即可。2.2 Oracle 补丁级别11.2.0.4 不是终点PSU 必须打满11.2.0.4 是基础门槛但光有 base version 不够。Oracle 19C 的 DBUA 在 Pre-Upgrade Checks 阶段会运行utlu112i.sql11g 升级前检查脚本其中一条关键校验是SELECT * FROM v$version WHERE banner LIKE %PSU%—— 如果返回空DBUA 直接终止。你手里的 11.2.0.4 很可能是 2013 年的初始版11.2.0.4.0而 19C 要求至少是 PSU Oct 2020即 11.2.0.4.201020。验证方法-- 登录源库11g SQL SELECT BANNER FROM v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production PL/SQL Release 11.2.0.4.0 - Production CORE 11.2.0.4.0 Production TNS for Linux: Version 11.2.0.4.0 - Production NLSRTL Version 11.2.0.4.0 - Production -- 再查 PSU 信息关键 SQL SELECT ACTION, VERSION, COMMENTS FROM dba_registry_history WHERE ACTIONAPPLY AND BUNDLE_SERIESPSU ORDER BY ACTION_TIME DESC FETCH FIRST 1 ROW ONLY; ACTION VERSION COMMENTS ------- -------------- ---------------------------------------- APPLY 11.2.0.4.201020 PSU 11.2.0.4.201020 (OCT2020)如果VERSION字段不是11.2.0.4.201020或更高如 201117必须先打 PSU。下载地址在 My Oracle SupportMOS搜索 Patch 2029901311.2.0.4.201020解压后按opatch apply流程执行。血泪经验PSU 打完必须重启实例并运行$ORACLE_HOME/rdbms/admin/catbundle.sql psu apply否则 DBUA 仍会报ORA-00942: table or view does not exist找不到 registry history 表。2.3 磁盘空间与目录结构/u01 和 /u02 别混用ORACLE_HOME 必须独立DBUA 升级不是 in-place 替换而是“新家搬家”19C 的 ORACLE_HOME 必须是全新路径不能复用 11g 的/u02/app/oracle/product/11.2.0/db且需满足最小空间要求目录最小空间用途说明$ORACLE_HOME19C12 GB包含 binaries、network、rdbms 等DBUA 解压安装包后自动填充$ORACLE_BASE下diag目录10 GB存放 alert.log、trace 文件升级过程日志量极大$ORACLE_BASE/fast_recovery_area≥ 数据库大小 × 1.5DBUA 升级期间会生成大量临时归档和 flashback log/tmp≥ 2 GBDBUA 启动时解压 JAR 包、创建临时 Java 进程特别注意文中示例里源库 ORACLE_HOME 是/u02/app/oracle/product/11.2.0/db目标库是/u01/app/oracle/product/19.14.0/db_1这个分离是强制的。如果强行把 19C 装到/u02/app/oracle/product/19cDBUA 在Copying files to new Oracle home阶段会报SEVERE: java.io.IOException: No space left on device因为/u02分区实际只剩 8GB而 19C binaries 解压后占 11.2GB。解决方案不是清空间是立刻切到/u01确保df -h /u01显示 ≥15GB 可用。2.4 用户与权限oracle 用户的 umask 必须是 022别信“默认就好”DBUA 启动依赖 Java 进程而 Java 对文件权限极其敏感。如果oracle用户的umask是 002常见于某些 RHEL7 模板会导致$ORACLE_HOME/jdk/jre/lib/security/cacerts文件权限为664DBUA 启动时 Java 报java.security.InvalidKeyException: Wrong key usage进程静默退出$ORACLE_HOME/cfgtoollogs/dbua/logs下只有dbua-timestamp.log文件内容为空。验证和修复# 切换到 oracle 用户检查当前 umask su - oracle umask # 若输出 0002则立即修复 # 临时修复本次会话有效 umask 0022 # 永久修复修改 oracle 用户的 shell 配置 echo umask 0022 ~/.bash_profile source ~/.bash_profile # 验证新建文件权限应为 644而非 664 touch /tmp/testfile ls -l /tmp/testfile # 正确输出-rw-r--r-- 1 oracle oinstall 0 Aug 31 22:10 /tmp/testfile注意umask 0022是 Oracle 官方唯一认证值见 MOS Doc ID 1363422.1其他如0002或0077均会导致 DBUA 启动失败或升级后监听器无法注册。3. 备份与恢复RMAN 恢复不是“还原就行”控制文件、参数文件、归档缺一不可DBUA 升级要求目标库必须是一个“可打开的、一致的 11g 数据库副本”。很多人以为RESTORE DATABASE就完事了结果 DBUA 启动时报ORA-01102: cannot mount database in EXCLUSIVE mode查alert.log发现控制文件路径不对——这是因为 DBUA 会读取spfile中的control_files参数而你恢复时没改路径。恢复不是搬运是重置。3.1 参数文件重建pfile 里这 5 个参数必须手改DBUA 不认 ASM 路径源库用 ASM 存储DATA/bsoftsb/datafile/system.270.979224249但 DBUA 升级目标库必须是文件系统FS路径。所以pfile.ora里所有*.control_files、*.db_create_file_dest、*.db_recovery_file_dest必须从DATA/xxx改成/oradata/xxx。重点改以下 5 项其他保持原样# vim /home/oracle/pfile.ora *.control_files/oradata/bsoftsb/controlfile/control01.dbf # ← 必须是绝对路径且目录已存在mkdir -p *.db_create_file_dest/oradata # ← 数据文件根目录 *.db_recovery_file_dest/arch # ← 归档根目录需提前 mkdir -p /arch *.audit_file_dest/u02/app/oracle/admin/bsoftsb/adump # ← audit 目录注意不是 /u01 *.diagnostic_dest/u02/app/oracle # ← diag 根目录必须和 ORACLE_BASE 一致关键逻辑DBUA 升级过程中会调用srvctl和sqlplus / as sysdba启动实例它依赖pfile中的路径来定位控制文件。如果control_files还是DATA/...startup nomount pfile...会报ORA-00205: error in identifying control file因为目标主机没配 ASM 实例。3.2 控制文件恢复restore 后必须catalog start with否则 DBUA 找不到数据文件RMANrestore controlfile只恢复二进制文件但控制文件里记录的数据文件路径还是 ASM 的DATA/...。DBUA 启动时会扫描v$datafile发现路径不存在直接报ORA-01157: cannot identify/lock data file。必须用catalog命令把物理路径映射到控制文件中# 恢复控制文件后立即 catalog [oracleoracle19c:/hisbak]$ rman target / RMAN restore controlfile from /hisbak/BSOFT_CONT_562120512_20220830_40443.ctl; RMAN sql alter database mount; RMAN catalog start with /oradata/BSOFTSB/datafile/; # ← 关键指向你 restore 后的数据文件实际位置 # 输出应为cataloged datafile copy /oradata/BSOFTSB/datafile/system.270.979224249验证是否成功SQL SELECT name FROM v$datafile WHERE rownum 5; NAME ------------------------------------------------------------ /oradata/BSOFTSB/datafile/system.270.979224249 /oradata/BSOFTSB/datafile/sysaux.266.979223939 /oradata/BSOFTSB/datafile/undotbs1.269.979224213 /oradata/BSOFTSB/datafile/users.271.979224275如果name列还是DATA/...说明catalog没生效需检查/oradata/BSOFTSB/datafile/下文件是否存在路径是否拼写错误Linux 区分大小写。3.3 数据库恢复SET NEWNAME 是灵魂不设就恢复到 ASM 路径RESTORE DATABASE默认按控制文件里记录的路径恢复即DATA/...。但目标主机没 ASM必须强制重定向到文件系统。SET NEWNAME FOR DATABASE TO ...就是干这个的RMAN run { ALLOCATE CHANNEL C1 DEVICE TYPE DISK; SET NEWNAME FOR DATABASE TO /oradata/BSOFTSB/datafile/%b; # ← %b 是文件名占位符system.270.979224249 SET UNTIL TIME TO_DATE(2022-08-30:02:00:00, YYYY-MM-DD:HH24:MI:SS); RESTORE DATABASE; SWITCH DATABASE TO COPY; # ← 关键把控制文件里的路径更新为新路径 RELEASE CHANNEL C1; }SWITCH DATABASE TO COPY这一步不能省。它等价于执行ALTER DATABASE RENAME FILE DATA/... TO /oradata/...把控制文件元数据更新。没有它RECOVER DATABASE时 RMAN 会去DATA/...找归档报RMAN-06023: no backup or copy of datafile ... found to restore。3.4 归档日志追加recover 到时间点后必须list backup of archivelog验证可用性文中RECOVER DATABASE到2022-08-30:12:00:00后报RMAN-06054: media recovery requesting unknown archived log根本原因是归档备份集不连续。list backup of archivelog from time sysdate-1显示最后归档序列是25192但 recovery 请求的是25197中间缺了25193-25196。这不是 DBUA 的锅是备份策略缺陷。解决方案# 方案1补全归档如果有归档文件只是没备份 cp /arch/1_25193_1040307001.dbf /hisbak/ # 假设归档在 /arch 下 rman target / EOF catalog archivelog /hisbak/1_25193_1040307001.dbf; catalog archivelog /hisbak/1_25194_1040307001.dbf; catalog archivelog /hisbak/1_25195_1040307001.dbf; catalog archivelog /hisbak/1_25196_1040307001.dbf; EOF # 方案2降级 recovery 时间点推荐用于测试环境 RUN { ALLOCATE CHANNEL C1 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; }避坑提示DBUA 升级前目标库必须处于OPEN READ ONLY状态且SELECT CURRENT_SCN FROM V$DATABASE返回的 SCN 必须大于等于你计划升级的 SCN。否则 DBUA 会拒绝启动报ORA-01034: ORACLE not available实际是 SCN 不匹配。4. DBUA 升级执行图形界面 vs 静默模式参数陷阱比想象中多DBUA 启动方式有两种GUI 图形界面$ORACLE_HOME/bin/dbua和静默模式dbua -silent。生产环境必须用静默模式因为 GUI 依赖 X11 转发而多数服务器禁用xhost 导致Cant open display错误。但静默模式参数稍有不慎就会失败。4.1 静默模式核心参数-sid、-oracleHome、-sourceDB 一个都不能少DBUA 静默模式必须显式指定 3 个参数缺一不可参数示例值说明-sidbsoftsb目标库实例名必须和pfile.ora中db_name一致-oracleHome/u01/app/oracle/product/19.14.0/db_119C 的 ORACLE_HOME必须绝对路径-sourceDB/u02/app/oracle/product/11.2.0/db11g 的 ORACLE_HOME用于读取升级脚本完整命令# 切换到 19C 的 oracle 用户注意不是 11g 的 oracle su - oracle # 设置环境变量指向 19C HOME export ORACLE_HOME/u01/app/oracle/product/19.14.0/db_1 export PATH$ORACLE_HOME/bin:$PATH # 执行静默升级 $ORACLE_HOME/bin/dbua -silent \ -sid bsoftsb \ -oracleHome /u01/app/oracle/product/19.14.0/db_1 \ -sourceDB /u02/app/oracle/product/11.2.0/db \ -logDestination /u01/app/oracle/cfgtoollogs/dbua_upgrade \ -ignoreSysPrereqs \ -upgradeTimezone注意-ignoreSysPrereqs这是绕过 OS 版本检查的“后悔药”仅限测试环境使用。生产环境必须确保 OS 符合要求否则升级后监听器注册失败。4.2 日志分析upgrade.xml是黄金线索别只盯dbua.logDBUA 升级过程生成两类日志$ORACLE_HOME/cfgtoollogs/dbua/timestamp/dbua.log启动流程日志报错多在此处$ORACLE_HOME/cfgtoollogs/dbua/timestamp/upgrade.xml结构化升级步骤日志含每个 SQL 脚本执行状态当 DBUA 卡在Executing pre-upgrade checks时dbua.log可能只显示INFO: Starting pre-upgrade checks...但upgrade.xml里会有具体 SQL!-- upgrade.xml 片段 -- step idpreupgrade_checks statusFAILED sqlSELECT COUNT(*) FROM dba_registry WHERE comp_idCATALOG AND status!VALID/sql errorORA-00942: table or view does not exist/error /step这说明dba_registry视图损坏需在 11g 源库运行?/rdbms/admin/utlrp.sql重新编译无效对象。4.3 升级中断处理-restart不是万能要结合upgrade.xml的 step idDBUA 升级中途失败如网络断开再次运行dbua -silent -restart会从上次失败的 step 继续。但前提是upgrade.xml中该 step 的status是FAILED而非COMPLETED。如果因磁盘满导致statusIN_PROGRESS卡住-restart会报No failed steps found to restart。此时需手动清理# 删除失败的升级会话谨慎确保无其他 DBUA 进程 rm -rf $ORACLE_HOME/cfgtoollogs/dbua/failed_timestamp # 清理 19C ORACLE_HOME 下残留文件避免冲突 rm -f $ORACLE_HOME/dbs/spfilebsoftsb.ora rm -f $ORACLE_HOME/dbs/initbsoftsb.ora # 重启数据库到 nomount再运行 DBUA sqlplus / as sysdba EOF shutdown abort; startup nomount pfile/home/oracle/pfile.ora; exit EOF4.4 常见问题与排查5 条血泪踩坑记录现象 1DBUA 启动报java.lang.NoClassDefFoundError: oracle/sysman/emSDK/emd/util/EMDUtil原因19C 的$ORACLE_HOME/jdk/jre/lib/ext/下缺少emSDK.jar该 jar 由 11g 的ORACLE_HOME/rdbms/jlib/emSDK.jar提供但 DBUA 静默模式未自动加载。解决手动复制 jar 到 19C JDK 扩展目录cp /u02/app/oracle/product/11.2.0/db/rdbms/jlib/emSDK.jar /u01/app/oracle/product/19.14.0/db_1/jdk/jre/lib/ext/现象 2升级完成后lsnrctl status显示Service bsoftsb has 1 instance(s)但tnsping bsoftsb超时原因listener.ora中SID_LIST_LISTENER未添加 19C 实例DBUA 不修改监听配置。解决编辑$ORACLE_HOME/network/admin/listener.ora在SID_LIST_LISTENER下添加(SID_DESC (GLOBAL_DBNAME bsoftsb) (ORACLE_HOME /u01/app/oracle/product/19.14.0/db_1) (SID_NAME bsoftsb) )然后lsnrctl reload。现象 3升级后SELECT * FROM v$version显示19.14.0.0.0但SELECT * FROM v$database的COMPATIBLE还是11.2.0.4.0原因DBUA 不自动修改compatible参数需手动升级。解决升级后立即执行SQL ALTER SYSTEM SET compatible19.0.0 SCOPESPFILE; SQL shutdown immediate; SQL startup;现象 4utlrp.sql编译失败dba_objects中STATUSINVALID对象超 200 个原因11g 中JAVA组件未完全升级dbms_java包失效。解决在 19C 环境下运行 Java 升级脚本$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catqm.pl sys_password SYSAUX TEMP NO $ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catjava.pl sys_password现象 5DBUA 升级完成但SELECT * FROM v$option WHERE parameterOracle Database Vault返回FALSE而源库是TRUE原因Database Vault 是独立选项DBUA 不迁移其配置。解决手动启用需先安装 DV 组件# 以 19C oracle 用户执行 $ORACLE_HOME/bin/catdw.sh -i /u01/app/oracle/product/19.14.0/db_1 -d bsoftsb -s sys_password # 然后 SQL*Plus 中启用 SQL EXEC DBMS_RULE_ADM.GRANT_SYSTEM_PRIVILEGE(ADMINISTER DATABASE TRIGGER, DV_OWNER); SQL ALTER SYSTEM SET audit_trailDB,EXTENDED SCOPESPFILE;5. 升级后验证与性能调优从SELECT * FROM v$version到 AWR 报告对比装完不是终点验证才是开始。DBUA 升级成功只代表数据库能OPEN不代表业务能跑。我见过升级后应用连不上查alert.log发现ORA-28001: the password has expired—— 因为 19C 默认PASSWORD_LIFE_TIME180而 11g 是UNLIMITED。验证必须覆盖连接性、功能、性能三层。5.1 基础连接性验证tnsping、sqlplus、JDBC 三连击不能只信sqlplus / as sysdba。必须模拟真实应用连接# 1. tnsping 检查网络层 tnsping bsoftsb # 应输出OK (0 msec) # 2. sqlplus 检查 SQL 层用普通用户非 sys sqlplus app_user/app_passbsoftsb EOF SELECT COUNT(*) FROM user_tables; EXIT EOF # 应返回正常行数而非 ORA-01017密码过期 # 3. JDBC 检查驱动兼容性Java 应用必做 # 编译测试类需 ojdbc8.jar javac -cp .:ojdbc8.jar JdbcTest.java java -cp .:ojdbc8.jar JdbcTest # JdbcTest.java 内容 # Class.forName(oracle.jdbc.driver.OracleDriver); # Connection conn DriverManager.getConnection(jdbc:oracle:thin:192.168.6.132:1521/bsoftsb, app_user, app_pass); # System.out.println(Connected: conn.isClosed());提示19C 默认禁用SEC_CASE_SENSITIVE_LOGONFALSE但 JDBC 连接字符串需显式加?useSSLfalseallowPublicKeyRetrievaltrue否则报ORA-28040: No matching authentication protocol。5.2 功能完整性验证dba_registry、v$option、utlrp.sql三张表升级后第一件事不是跑业务是查数据库自身健康度-- 1. 检查组件状态必须全 VALID SELECT comp_name, status, version FROM dba_registry ORDER BY comp_name; -- 2. 检查选项启用情况对比升级前 SELECT parameter, value FROM v$option WHERE parameter IN (Oracle Database Vault, Oracle Label Security, Oracle Real Application Testing); -- 3. 编译所有无效对象必须 0 行 ?/rdbms/admin/utlrp.sql SELECT COUNT(*) FROM dba_objects WHERE statusINVALID;关键指标dba_registry中ORDIMOracle Multimedia、XDBXML DB状态必须是VALID否则SELECT XMLTYPE(a1/a) FROM dual会报ORA-00904: XMLTYPE: invalid identifier。5.3 性能基线对比AWR 报告不是看数字是看 Top 5 Event 变化升级前后各取一份 1 小时 AWR 报告用awrrpt.sql重点对比指标11g 典型值19C 典型值异常信号Top 5 Timed Eventsdb file sequential read,log file syncdb file scattered read,enq: TX - row lock contention若log file sync时间突增 200%说明 Redo Log 配置需调优SQL ordered by Elapsed TimeINSERT /* APPEND */占比高SELECT /* FULL */占比高若全表扫描 SQL 增多检查optimizer_features_enable是否被重置为11.2.0.4Instance Efficiency PercentagesBuffer Nowait % 99Buffer Nowait % 99.9健康信号说明内存管理优化生成报告命令# 登录 19C 数据库 sqlplus / as sysdba SQL ?/rdbms/admin/awrrpt.sql # 选择 report type: 1 (HTML), 输入 begin snap: 100, end snap: 101 # 报告生成路径$ORACLE_HOME/rdbms/admin/awrrpt_1_100_101.html5.4 兼容性参数调优optimizer_features_enable必须设为19.1.0否则执行计划倒退19C 默认optimizer_features_enable19.1.0但 DBUA 升级会继承 11g 的值11.2.0.4。这会导致 SQL 执行计划用旧规则SELECT /* USE_NL(t1,t2) */失效全表扫描变多。验证和修复-- 查看当前值 SQL SHOW PARAMETER optimizer_features_enable NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ optimizer_features_enable string 11.2.0.4 -- 立即修复影响所有 session SQL ALTER SYSTEM SET optimizer_features_enable19.1.0 SCOPEBOTH; -- 验证执行计划是否变化 EXPLAIN PLAN FOR SELECT * FROM users WHERE usernameSYS; SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY); -- 正确输出中应有 19.1.0 字样注意optimizer_features_enable是动态参数SCOPEBOTH即刻生效无需重启。但若应用有绑定变量窥探bind peeking问题建议同时设置optimizer_adaptive_statisticsFALSE19C 默认 TRUE。5.5 回滚预案验证flashback database不是摆设必须真跑一遍升级前你做了 RMAN 全备但回滚时RESTORE DATABASE要 2 小时。而flashback database只需 5 分钟。但很多人升级后忘了开启 flashback-- 升级后立即检查 SQL SELECT flashback_on FROM v$database; -- 若返回 NO则开启需先 mount SQL SHUTDOWN IMMEDIATE; SQL STARTUP MOUNT; SQL ALTER DATABASE FLASHBACK ON; SQL ALTER DATABASE OPEN; -- 验证 flashback 日志生成 SQL SELECT * FROM v$flashback_database_log; -- OUTPUT_BYTES 应 0且 OLDEST_FLASHBACK_TIME 不是 null从那以后我每次升级前都强制走一遍flashback database的全流程SHUTDOWN IMMEDIATE→STARTUP MOUNT→FLASHBACK DATABASE TO BEFORE RESETLOGS→ALTER DATABASE OPEN RESETLOGS确保回滚通道畅通。希望帮到你。本文还有配套的精品资源点击获取