简介：本资源是一份面向Oracle数据库管理员（DBA）的实战型升级指南，聚焦使用Database Upgrade Assistant（DBUA）将生产环境中的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.201020（PSU 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.18，DBUA 反而可能报错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/rvu（Real 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.sql（11g 升级前检查脚本），其中一条关键校验是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 ACTION='APPLY' AND BUNDLE_SERIES='PSU' 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 Support（MOS）搜索 Patch 20299013（11.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_HOME（19C） | 12 GB | 包含 binaries、network、rdbms 等，DBUA 解压安装包后自动填充 |
$ORACLE_BASE下diag目录 | 10 GB | 存放 alert.log、trace 文件，升级过程日志量极大 |
$ORACLE_BASE/fast_recovery_area | ≥ 数据库大小 × 1.5 | DBUA 升级期间会生成大量临时归档和 flashback log |
/tmp | ≥ 2 GB | DBUA 启动时解压 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/19c，DBUA 在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文件权限为664，DBUA 启动时 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 [oracle@oracle19c:/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 +，导致Can't open display错误。但静默模式参数稍有不慎就会失败。
4.1 静默模式核心参数：-sid、-oracleHome、-sourceDB 一个都不能少
DBUA 静默模式必须显式指定 3 个参数，缺一不可：
| 参数 | 示例值 | 说明 |
|---|---|---|
-sid | bsoftsb | 目标库实例名（必须和pfile.ora中db_name一致） |
-oracleHome | /u01/app/oracle/product/19.14.0/db_1 | 19C 的 ORACLE_HOME（必须绝对路径） |
-sourceDB | /u02/app/oracle/product/11.2.0/db | 11g 的 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.log
DBUA 升级过程生成两类日志：
$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 id="preupgrade_checks" status="FAILED"> <sql>SELECT COUNT(*) FROM dba_registry WHERE comp_id='CATALOG' AND status!='VALID'</sql> <error>ORA-00942: table or view does not exist</error> </step>这说明dba_registry视图损坏，需在 11g 源库运行@?/rdbms/admin/utlrp.sql重新编译无效对象。
4.3 升级中断处理：-restart不是万能，要结合upgrade.xml的 step id
DBUA 升级中途失败（如网络断开），再次运行dbua -silent -restart会从上次失败的 step 继续。但前提是upgrade.xml中该 step 的status是FAILED而非COMPLETED。如果因磁盘满导致status="IN_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 条血泪踩坑记录
现象 1：DBUA 启动报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 compatible='19.0.0' SCOPE=SPFILE; SQL> shutdown immediate; SQL> startup;现象 4：utlrp.sql编译失败，dba_objects中STATUS='INVALID'对象超 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现象 5：DBUA 升级完成，但SELECT * FROM v$option WHERE parameter='Oracle 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_trail=DB,EXTENDED SCOPE=SPFILE;5. 升级后验证与性能调优：从SELECT * FROM v$version到 AWR 报告对比
装完不是终点，验证才是开始。DBUA 升级成功只代表数据库能OPEN，不代表业务能跑。我见过升级后应用连不上，查alert.log发现ORA-28001: the password has expired—— 因为 19C 默认PASSWORD_LIFE_TIME=180，而 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_pass@bsoftsb <<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_LOGON=FALSE，但 JDBC 连接字符串需显式加?useSSL=false&allowPublicKeyRetrieval=true，否则报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 status='INVALID';关键指标：dba_registry中ORDIM（Oracle Multimedia）、XDB（XML DB）状态必须是VALID，否则SELECT XMLTYPE('<a>1</a>') FROM dual会报ORA-00904: "XMLTYPE": invalid identifier。
5.3 性能基线对比：AWR 报告不是看数字，是看 Top 5 Event 变化
升级前后各取一份 1 小时 AWR 报告（用awrrpt.sql），重点对比：
| 指标 | 11g 典型值 | 19C 典型值 | 异常信号 |
|---|---|---|---|
| Top 5 Timed Events | db file sequential read,log file sync | db file scattered read,enq: TX - row lock contention | 若log file sync时间突增 200%，说明 Redo Log 配置需调优 |
| SQL ordered by Elapsed Time | INSERT /*+ APPEND */占比高 | SELECT /*+ FULL */占比高 | 若全表扫描 SQL 增多，检查optimizer_features_enable是否被重置为11.2.0.4 |
| Instance Efficiency Percentages | Buffer Nowait %< 99 | Buffer 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_enable='19.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_enable='19.1.0' SCOPE=BOTH; -- 验证：执行计划是否变化 EXPLAIN PLAN FOR SELECT * FROM users WHERE username='SYS'; SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY); -- 正确输出中应有 "19.1.0" 字样注意：
optimizer_features_enable是动态参数，SCOPE=BOTH即刻生效，无需重启。但若应用有绑定变量窥探（bind peeking）问题，建议同时设置optimizer_adaptive_statistics=FALSE（19C 默认 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，确保回滚通道畅通。希望帮到你。
本文还有配套的精品资源，点击获取
