简介：这份面向数据库管理员的 Oracle 11g 升级 19C 实操手册，围绕 DBUA（Database Upgrade Assistant）展开，帮助仍在运行已停止补丁更新的 11g 环境中的团队，按可控顺序完成向 19C 的迁移。内容从前期备份讲起，演示用 RMAN 把生产库恢复到独立测试库、保留原库用于失败回退的做法，并给出 pfile 参数改写要点；随后依次覆盖环境规划表（主机版本、IP、源库与目标库版本、ORACLE_HOME 路径）、DBUA 图形界面与静默两种升级方式、直接与间接升级路线对照，以及 19C 对 Linux 7 最低主机版本等前提约束，并列出可供溯源的 MOS 参考文档编号。作者对检查脚本生成的日志与警告单独强调，附有多个故障处理方案，便于异常时快速定位。全部内容收在一个 PDF 文件中，压缩包约 3.18MB，篇幅紧凑但保留大量命令细节与严格顺序要求，可作升级前通读、升级中随时翻阅的检查清单。已有 1361 人学习下载。

1. 一套 11.2.0.4 的业务库要迁到 19C，DBUA 是最省事的把手

去年帮朋友看一套系统，v$version里躺着 11.2.0.4.201020，最后一次打补丁还是三年前，扫描报告上补丁缺失项一长串。业务不能停太久，运维只有两个人，老板给的窗口就一个周末。这种局面下，手工catupgrd.sql一路跑下来，中间任何一步报错都得从头捋，而 DBUA（Database Upgrade Assistant）把检查、升级、时区转换、无效对象编译、统计信息收集串成了一条流水线，图形界面点几下、日志里看清楚，比敲几百行 SQL 稳得多。手里这份《Oracle 11g 到 19C 数据库升级详尽指导手册》讲的就是这条路：源库 11.2.0.4 不动机器不动数据，通过 RMAN 把库搬到一台 RHEL7.9 的 19C 主机上，再用 DBUA 完成升级。适合有基本 RMAN 恢复能力、手里真有一套生产库等着迁的人，不适合连startup mount都要查手册的新手。

2. 升级路线先算清：版本、主机与 precheck 三道闸

升级这件事，真正决定成败的不是 DBUA 点得快不快，而是动手之前有没有把版本路线和主机条件算明白。原手册里那张升级路线表看着枯燥，实际是排雷图——走错路线，DBUA 在检查阶段就会给你一个下马威，白熬一个通宵。

2.1 哪些版本能一步到 19C，哪些必须先垫一脚

Oracle 的跨大版本升级不是随便跳的。19C 只接受几个特定源版本直上，其余都得先在中间版本落一次脚，再往 19C 走。原手册给的这两张表是核心，我按实操视角重新整理了一遍：

这张表里最容易翻车的是 11.2.0.1/2/3 那一档。很多老系统装的是 11.2.0.3，觉得"就差一个小版本号，直接冲 19C 试试"，DBUA 会明确告诉你源版本不受支持。补丁包31537677这类 11.2.0.4 的补丁集，是绕不过去的一道坎。定路线的时候先把select * from v$version;的结果贴到文档里，对照表格在纸上画一遍路径，确认只有一跳还是两跳，再决定周末够不够用。两跳意味着要做两次升级、两次全量备份、两次回归验证，时间预算至少翻倍。

2.2 RHEL7 是硬门槛，机器不够就得另起一台

19C 对操作系统的最低要求是 Linux 7。11g 时代大量系统跑在 RHEL6 上，这一条直接把"原地升级"的念头掐死了。硬在 RHEL6 上装 19C 软件，安装器不一定当场拒绝你，但后面 DBUA 检查、补丁安装、甚至实例启动都可能出现莫名其妙的异常，这种玄学问题排查起来最费时间。

原手册给出的解法很务实：如果源库主机是 Linux 6，就别折腾原地升级了，新开一台 RHEL7 装 19C 软件（只装软件，不建库），把生产库通过 RMAN 备份恢复到这台机器上，让它扮演"升级环境"。这套做法有三个好处：生产库全程不动，出任何问题业务不受影响；升级失败直接删掉目标库重来，没有后悔药也不怕；升级完成后还能做一段时间的双跑比对。代价是需要额外的存储和一台机器，但比起停机窗口里手忙脚乱，这点成本值得。

装 19C 软件的时候有个细节要注意：只装软件、不创建数据库，安装类型选"仅安装数据库软件"。装完别急着建监听建库，后面 DBUA 需要的是一个干净的、没有实例的ORACLE_HOME。

2.3 三个 precheck：preupgrade.jar、组件清单、SYSAUX 余量

正式开升级窗口之前，至少留出半天专门跑预检查，把能提前解决的问题解决掉。19C 的ORACLE_HOME下自带preupgrade.jar，它能在不升级的情况下扫出绝大多数阻碍，这是我最看重的一步。

# 切到 19C 的 ORACLE_HOME，注意不是源库的 home export ORACLE_HOME=/u01/app/oracle/product/19.14.0/db_1 export PATH=$ORACLE_HOME/bin:$PATH export ORACLE_SID=orcl # preupgrade.jar 要求 JDK，直接用 19C 自带的即可 # FILE TEXT 表示输出纯文本报告，DIR 指定报告落地目录，先建好 mkdir -p /tmp/preup $ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/rdbms/admin/preupgrade.jar \ FILE TEXT DIR /tmp/preup # 跑完会生成 preupgrade.log / preupgrade_fixups.sql / postupgrade_fixups.sql ls -l /tmp/preup

这段命令的关键在三个参数：FILE TEXT决定报告格式，纯文本比 HTML 方便 grep；DIR指定的目录必须提前存在，jar 不会替你建；执行时ORACLE_SID要指向待升级的源库，jar 是通过实例连进去做检查的。生成的preupgrade_fixups.sql是升级前要执行的修复脚本，postupgrade_fixups.sql留到升级后跑，两个文件都别丢。

除了 jar 的报告，我习惯自己再手工确认三件事。组件状态，一条 SQL 看清楚：

-- 检查组件版本和状态，INVALID 或 UPGRADED 状态的组件都要留意 select comp_id, comp_name, version, status from dba_registry order by comp_id; -- 时区文件版本，19C 要求至少 26，11.2.0.4 通常只有 18 左右 select * from v$timezone_file; -- 无效对象数量，升级前先记个基线，升级后好对比 select count(*) from dba_objects where status = 'INVALID';

组件里最容易被忽略的是 APEX、OWMS、JAVA VIRTUAL MACHINE 这几个。如果 APEX 版本太老，DBUA 升级到一半会因为组件脚本报错停下来；稳妥做法是升级前把不用的组件卸掉，或者先把 APEX 升到 19C 支持的版本。时区文件版本是另一个高频拦截点，11.2.0.4 自带的时区版本通常是 18，达不到 19C 要求的 26，DBUA 会在升级过程中做时区转换，这一步会重写所有带TIMESTAMP WITH TIME ZONE列的数据，大表上耗时不可小觑，窗口要留够。

SYSAUX 的空间也要提前看，19C 的统一审计、AWR、优化器统计信息都要往这里塞东西，我一般要求升级前 SYSAUX 至少有 2GB 以上空闲，不够就提前加数据文件。

-- 看 SYSAUX 剩余空间，MB 为单位 select tablespace_name, round(sum(bytes)/1024/1024) total_mb, round(sum(maxbytes)/1024/1024) max_mb from dba_data_files where tablespace_name = 'SYSAUX' group by tablespace_name;

3. 用 RMAN 把生产库搬到升级机：一条能回退的恢复链

目标机装好 19C 软件之后，接下来要做的不是直接开 DBUA，而是把源库完整地"搬"过来。这一步手册写得非常细，因为它决定了后面升级失败时你有没有退路——生产库原封不动待在那儿，目标库随便你怎么折腾。

3.1 参数文件和控制文件先落地

恢复的起点是参数文件。源库的 spfile 备份是现成的，先startup nomount把它还原成 pfile，改掉路径和库名相关参数，再生成目标库自己的 spfile。

# 目标机上，先让环境指向 19C 的 home 和空的实例 export ORACLE_HOME=/u02/app/oracle/product/11.2.0/db export ORACLE_SID=bizdb export PATH=$ORACLE_HOME/bin:$PATH # 起一个空实例，只为还原 spfile rman target /

RMAN> startup nomount; RMAN> restore spfile from '/hisbak/spfile_BIZDB_20220830_40444.ora'; RMAN> exit -- 用还原出来的 spfile 反向生成可编辑的 pfile SQL> create pfile='/home/oracle/pfile.ora' from spfile; SQL> exit

restore spfile这一步只写文件不启动实例，所以nomount足够。生成的 pfile 里有一批参数必须手工改：audit_file_dest、control_files、db_recovery_file_dest、diagnostic_dest这些带绝对路径的，全部指向目标机的目录结构；db_name保持和源库一致，只改db_unique_name，这是最省事的做法——改db_name得走 NID 那一套流程，属于另一个话题，没必要在这个窗口里给自己加戏。

改完 pfile 之后，两个目录要先手工建出来，否则startup nomount会直接报错：

mkdir -p /u02/app/oracle/admin/bizdb/adump mkdir -p /oradata/bizdb/controlfile/ # 用 pfile 起实例，再据此生成目标库自己的 spfile sqlplus / as sysdba

SQL> startup nomount pfile='/home/oracle/pfile.ora'; SQL> create spfile='/u02/app/oracle/product/11.2.0/db/dbs/spfilebizdb.ora' from pfile='/home/oracle/pfile.ora'; SQL> shutdown immediate; SQL> startup nomount;

参数里有两个值得单独说。memory_target和sga_target在目标机上按实际内存重新算，别照抄源库，源库可能是 128G 的机器，目标机只有 64G，参数照搬会直接起不来。sec_case_sensitive_logon如果源库里是FALSE，先留着别动，19C 里这个参数已经废弃，升级后要单独处理密码验证问题，放到避坑那章细说。

3.2 restore 和 recover 拆成两段，时间点自己控

控制文件还原之后 mount，把备份目录 catalog 进来，就能看到备份集了。手册里把 restore 和 recover 拆成两个独立步骤，中间还分了三次不同时间点的 recover，这个做法看着啰嗦，实际很实用——备份恢复往往跨越好几个小时，先恢复到某个较早的时间点，确认库能打开，再一步步往前追归档，出问题时知道是哪一段出的问题。

# 还原控制文件到 pfile 里指定的路径 rman target /

RMAN> restore controlfile from '/hisbak/BIZDB_CONT_20220830_40443.ctl'; RMAN> sql 'alter database mount'; RMAN> catalog start with '/hisbak/'; RMAN> report schema;

catalog start with会把目录下所有备份片登记进控制文件，跑完report schema就能看到数据文件的清单。这里有个细节：如果备份来自 ASM 存储，report schema里会显示+DATA/...这类路径，这是正常的，后面的SET NEWNAME会把它们全部重定向到本地文件系统。

RMAN> run { allocate channel c1 device type disk; -- 通道数按目标机 CPU 和磁盘 IO 调，16 个是原手册的量级，小机器开 4 到 8 个就够 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/bizdb/datafile/%b'; -- 只还原到这个时间点，后面的归档留着 recover 阶段追 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 FOR DATABASE TO '...%b'是整段脚本的核心，%b是 RMAN 的占位符，代表原数据文件名，这样 48 个数据文件不用一个个手写映射。SET UNTIL TIME卡住还原的上界，避免 RMAN 一路还原到最新导致窗口不可控。通道数量的经验值是目标机物理核数的一半左右，开太多反而因为 IO 争抢变慢。

还原完成后必须执行一次SWITCH DATABASE TO COPY，让控制文件里的数据文件路径真正指向新位置，漏了这一步，后面 recover 会找不到文件。

RMAN> switch database to copy; 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; -- 第一次 recover 推到 07:00，归档够就继续往后推 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; }

3.3 read only 打开验证，归档到位就继续往前追

恢复到一个中间时间点之后，用alter database open read only打开看一眼，确认数据字典能读、关键表能查，再关掉继续追归档。这个动作看起来多余，实际上是最便宜的验证手段——只读打开不产生 redo，也不会污染恢复链路，一旦发现数据文件损坏，这时候重来比升级到一半再发现要划算得多。

SQL> alter database open read only; -- 随便查几张核心业务表，确认数据在 SQL> select count(*) from biz_order; SQL> shutdown abort; SQL> startup mount;

要继续往前追，必须回到 mount 状态，shutdown abort在这里是可以接受的，因为这个库本来就没有对外提供服务。追归档的 recover 不写SET UNTIL TIME，RMAN 会一直应用到归档耗尽为止，报RMAN-06054: media recovery requesting unknown archived log是正常的结束信号，说明手上的归档已经全部应用完了。

手册里那套"备份恢复到 02:00、追到 07:00、再追到 12:00、最后追到归档尽头"的节奏，本质是在控制不确定性。每追一段就验证一次，比一口气追到底然后发现某个归档缺失要强得多。归档不够的时候，只能停在最后一个能应用的 SCN，用只读方式打开做升级前的数据校验，正式升级窗口再重新做一次全量恢复。这个取舍要在排计划的时候就定下来，别等到窗口里临时决策。

4. DBUA 实操：图形界面和静默模式两条路

库恢复到位、能正常 mount 之后，重头戏才刚开始。DBUA 的图形界面很直观，但真正决定升级顺不顺的是启动之前的几个环境细节，以及界面上那几页选项怎么选。

4.1 拉起 DBUA 之前，环境变量和监听必须先对齐

DBUA 是从 19C 的ORACLE_HOME里启动的，但它要操作的是 11.2.0.4 的库，这个"跨 home"的特性是很多问题的源头。启动之前的检查清单：

监听这一条要单独强调。升级过程中 DBUA 需要通过监听连库，如果监听还挂在 11g 的 home 上，会出现"能连上但版本不匹配"的怪现象。正确做法是在 19C 的 home 下配置并启动 listener，端口可以和原来一样，但ORACLE_HOME必须是 19C 的。

# 确认环境变量全部指向 19C export ORACLE_HOME=/u01/app/oracle/product/19.14.0/db_1 export ORACLE_BASE=/u01/app/oracle export ORACLE_SID=bizdb export PATH=$ORACLE_HOME/bin:$PATH export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH # 确认 oratab 里有源库条目 grep -i bizdb /etc/oratab # 在 19C home 下起监听 lsnrctl status lsnrctl start # 确认库处于 mount 状态，DBUA 要求源库不能是 open 状态 sqlplus / as sysdba

SQL> select name, open_mode from v$database; -- 期望看到 MOUNTED，如果是 READ WRITE 要先 shutdown 再 startup mount

4.2 图形界面六页，每页都有必须做的选择

$ORACLE_HOME/bin/dbua启动之后，界面上的操作路径大致是这样：

第一页选库。DBUA 会扫描/etc/oratab和当前ORACLE_HOME下的实例，正常情况下目标库会出现在列表里。如果列表是空的，八成是 oratab 没配对或者ORACLE_SID不对。

第二页是前置检查。DBUA 会自己跑一遍 precheck，把preupgrade.jar发现的问题再确认一次。这一页出现的警告要逐条看，Warning级别的可以带过，Error级别的必须解决才能继续。常见的有 SYSAUX 空间不足、组件状态异常、时区版本过低、COMPATIBLE参数不符合要求。

第三页是升级选项，这里有几个勾选框值得展开。重新编译无效对象必须勾上，19C 升级后大量对象需要重编，让 DBUA 自动做省事；升级时区文件也建议勾上，否则升级完还得手工跑一遍DBMS_DST；收集统计信息看窗口，业务库大表多的话这一项耗时不短，可以放到升级后单独跑，但数据库刚升完统计信息是新的，优化器需要它，我一般建议勾上，用GATHER_STATS_JOB类似的机制在后台跑。

第四页是备份选项。DBUA 支持在升级前自动做一次 RMAN 备份，这个功能在空间够的情况下强烈建议打开，等于给自己留了一层保险。空间紧张的话，至少保证手工备份是完整的。

第五页是COMPATIBLE参数。这里要特别小心：DBUA 会把compatible提到19.0.0，而这个动作是不可逆的——一旦设成 19.0.0，再想退回到 11.2.0.4 就不可能了，只能通过备份恢复整库。如果业务上需要一段观察期，可以先手动把compatible保持在11.2.0.4，升级完成、业务验证通过之后再ALTER SYSTEM SET COMPATIBLE='19.0.0' SCOPE=SPFILE并重启。代价是这段时间用不上 19C 的部分新特性，收益是万一要回退，还有一条相对轻松的路。

第六页是摘要页，确认之后点完成，DBUA 开始干活。整个升级过程会持续几十分钟到几个小时不等，取决于库大小、时区转换的数据量和无效对象的数量。全程不要关窗口、不要中断监听、不要在这个实例上跑别的操作。

4.3 静默模式：批量升级和无人值守的备选

图形界面适合单库升级，如果手上有多个库要迁，或者升级窗口在半夜、不想守着屏幕，DBUA 支持静默模式。原手册引用的那份 MOS 文档（Doc ID 2548985.1）专门讲这个用法，命令形态大致如下：

# 静默模式启动 DBUA，核心参数是 sid 和目标 home $ORACLE_HOME/bin/dbua -silent \ -sid bizdb \ -oracleHome $ORACLE_HOME \ -sysDBAUserName sys \ -sysDBAPassword "your_password" \ -diagnosticDest /u01/app/oracle/cfgtoollogs/dbua \ >> /home/oracle/dbua_run.log 2>&1

参数说明：-sid指定待升级实例，-oracleHome指定 19C 的软件目录，-sysDBAUserName和-sysDBAPassword是连接凭据，-diagnosticDest指定日志落地目录。不同小版本支持的开关略有差异，动手前用dbua -help对照一下自己环境里的实际参数列表，别直接抄。静默模式下没有交互，所有选项走默认值，所以要提前确认默认的COMPATIBLE设置、是否自动备份这些行为符合预期。建议先在测试库上跑一遍静默流程，把生成的响应参数记下来，再上生产。

无论图形还是静默，日志都在同一个地方：

# 升级日志和摘要，出问题第一个看这里 ls -l $ORACLE_BASE/cfgtoollogs/dbua/bizdb/upgrade/ # preupgrade.log / postupgrade.log / upgradeSummary.html

upgradeSummary.html是升级结果的汇总页，哪些步骤成功、哪些失败、耗时多少，一目了然，比在终端里翻几十页日志高效得多。

4.4 升级完成之后必须手工做的收尾

DBUA 做到最后会提示升级成功，但"成功"不等于"能用了"。升级完成后必做的几件事：

-- 确认版本和打开模式 select * from v$version; select name, open_mode, log_mode from v$database; -- 组件状态，全部应为 VALID select comp_id, comp_name, version, status from dba_registry order by comp_id; -- 无效对象，数量应该很少或者为 0，多了就手工重编 select count(*) from dba_objects where status = 'INVALID'; -- 时区文件版本，应达到目标版本自带的水平 select * from v$timezone_file;

无效对象如果数量偏多，手工跑一遍@?/rdbms/admin/utlrp.sql，这个脚本可以重复执行，跑完再查一次。另外别忘了执行preupgrade.jar生成的那个postupgrade_fixups.sql，里面是针对具体库的修复动作，DBUA 不一定全覆盖。

5. 避坑与排查：五条血泪记录

升级这件事，顺的时候觉得简单，出问题时往往已经凌晨三点。下面这五条是这套流程里最常撞上的，按"现象 → 原因 → 解决"记下来，窗口里直接对号入座。

5.1 升级之前就会撞上的三类

现象一：DBUA 前置检查报时区版本不满足，或者升级卡在时区转换那一步特别久。

原因：11.2.0.4 自带的时区文件版本通常是 18，19C 要求至少 26。DBUA 在升级过程中会自动做时区转换，这个动作要重写所有带TIMESTAMP WITH TIME ZONE列的数据，表越大越慢，几个亿行的表能跑上小时级。

解决：升级前先查出带时区列的表，评估数据量，把这个耗时算进窗口。时间实在不够，可以在升级前用DBMS_DST手工做一次时区升级，把耗时挪到窗口之外。查看哪些表受影响：

-- 找出所有带 TIMESTAMP WITH TIME ZONE 列的表 select owner, table_name, column_name from dba_tab_cols where data_type like 'TIMESTAMP%WITH TIME ZONE%' and owner not in ('SYS','SYSTEM');

现象二：DBUA 启动后扫描不到目标库，列表是空的。

原因：/etc/oratab里没有源库条目，或者条目被注释了，或者ORACLE_HOME环境变量指向的不是 19C。DBUA 靠这两个地方定位实例。

解决：手工补 oratab 条目，格式是SID:ORACLE_HOME:N，然后把环境变量全部重新 export 一遍再启动 DBUA。改完用env | grep ORA确认一遍，别信"我记得改过了"。

现象三：prerequisite check 报 SYSAUX 空间不足，或者升级到 80% 突然报表空间无法扩展。

原因：19C 的统一审计表AUDSYS.AUD$UNIFIED、AWR 快照、优化器统计信息都往 SYSAUX 写，加上升级过程本身产生的中间数据，SYSAUX 的消耗比预期大得多。

解决：升级前把 SYSAUX 加到至少 2GB 空闲，空间不够就加数据文件并开自动扩展。别用"应该够了"这种判断，直接查数字：

-- 剩余空间低于 2GB 就先扩 select tablespace_name, round(sum(bytes)/1024/1024/1024, 2) total_gb, round(sum(maxbytes - bytes)/1024/1024/1024, 2) free_gb from dba_data_files where tablespace_name = 'SYSAUX' group by tablespace_name;

5.2 升完之后才发作的两类

现象四：升级成功，但 11g 的客户端连不上，报ORA-28040: No matching authentication protocol。

原因：19C 的sqlnet.ora默认SQLNET.ALLOWED_LOGON_VERSION_SERVER设成了 12，老客户端的认证协议版本太低，直接被拒。这是从 11g 迁到 19C 之后最高频的应用侧问题，升级窗口里数据库一切正常，第二天业务上班全炸。

解决：在目标库的$ORACLE_HOME/network/admin/sqlnet.ora里加上兼容设置，然后重启监听：

# 编辑 $ORACLE_HOME/network/admin/sqlnet.ora，追加两行 # SQLNET.ALLOWED_LOGON_VERSION_SERVER=8 # SQLNET.ALLOWED_LOGON_VERSION_CLIENT=8 lsnrctl reload

这是一条兼容性补丁，只能解燃眉之急。更彻底的做法是同步升级客户端驱动，把老客户端替换掉，毕竟 19C 已经在淘汰这些低版本协议了。

现象五：升级前能登的账号，升级后报ORA-01017: invalid username/password，密码明明没改。

原因：源库上sec_case_sensitive_logon设成了FALSE，靠大小写不敏感来兼容老应用。这个参数在 19C 里已经废弃，升级后验证逻辑改变，原来存的是 10G 版本的密码 verifier，19C 不认。

解决：升级前先把关键账号的密码重置一次，让它们在数据字典里生成当前版本能识别的 verifier；或者升级完成后统一ALTER USER ... IDENTIFIED BY ...重置一遍。要查哪些账号存在风险：

-- 查看密码 verifier 类型，10G 版本的存在兼容隐患 select username, password_versions from dba_users where account_status = 'OPEN' and username not in ('SYS','SYSTEM');

PASSWORD_VERSIONS里只有10G的账号，升级前必须处理。这个检查建议写进升级前清单，别等应用报错了才回头查。

6. 升级后验证与回退兜底：我的固定检查单

升级这件事，日志里显示Success只是起点，真正让人敢睡觉的是第二天业务跑通。我现在每次升级完都会走一遍固定的检查单，不凭感觉判断"应该没问题"。

这张表里我最看重的是最后两行。版本、组件这些是"数据库自己觉得好"，应用连不上、SQL 跑得慢，那才是真的出问题。升级后第一周我一般会盯着 AWR 看 top SQL 的变化，尤其是执行计划突变的语句——19C 的优化器行为跟 11g 有差异，某些依赖旧执行计划的 SQL 会突然变慢，这种问题不会在升级日志里体现，只能靠对比发现。

回退这件事，我的态度是"永远假设会失败"。源库在升级期间保持原样不动，目标库升级失败就地删掉重来；COMPATIBLE参数在业务验证通过前先不提到 19.0.0，留一条退路。这两个动作做足了，出问题的时候就是多花几个小时重来一遍，而不是在电话会议里解释为什么生产库回不去了。

有一次我在测试环境图省事，把compatible直接提到了 19.0.0，结果业务方反馈一个报表模块有问题，需要临时退回去确认是升级引起还是原本就有，结果发现回不去了，只能整库恢复，白丢了两天。从那以后我每次升级，COMPATIBLE这一步都强制留到业务验收之后单独做，宁可少用几天新特性，也不把自己逼到没有退路的位置。希望这套流程能帮到你，至少在下一个升级窗口里少踩两个坑。

本文还有配套的精品资源，点击获取