云海天狼兄弟们，聊到Oracle 19C升级，估计每位DBA心里都有一本血泪账。我当年第一次操作，从11.2.0.4往19C迁移，愣是踩了整整一周的坑，最后差点去客户现场跪键盘。现在回头看，好多问题根本不是技术多高深，而是“认证”这关没把住——不是指用户名密码那种认证，而是Oracle官方对升级链路、环境组合、组件兼容性的各种认证检查。这个细节，90%的DBA都会忽略，也正因为忽略，才会有那么多人折腾到后半夜。
这篇文章我就把那些年踩过的雷、翻过的车，以及后来整理出的升级避坑方案全部摊开来讲。内容适合正在规划19C升级、或者被升级方案折腾得睡不着觉的运维和DBA。不管你是刚接手数据库的新手，还是已经带团队的老手，这里面提到的步骤和坑，都能帮你省下至少一个月的加班时间。
1. 升级前必须搞懂的认证矩阵
1.1 什么是Oracle升级中的“认证”
先说个扎心的事实：Oracle 19C的升级，不只是拿个安装包跑一下脚本那么简单。整个升级过程本质上是一次“组合环境验证”，而Oracle官方对每个环节都有严格的Version Compatibility认证。这里的认证包括三层含义：
- 硬件与操作系统认证：检查你的CPU架构、OS发行版版本、内核参数、glibc版本是否在Oracle官方认证列表中。
- 数据库版本与升级路径认证：确认原库的版本是否在支持升级到19C的路径上，是否需要先升级到中间版本。
- 功能组件与选项认证：确认RAC、Data Guard、OGG、分区、高级压缩等组件在19C中的兼容状态。
很多DBA在升级前根本不看认证文档，直接拿安装包干。结果跑到一半脚本报错，弹出一堆关于“ORA-00439: feature not enabled”或者“prereq checks failed”的信息，人瞬间就懵了。其实这些错误绝大多数情况都能提前通过查认证文档规避，根本不该等到安装阶段才爆发。
我自己的习惯是，升级前必逛三个页面：Oracle Support Doc 2113164.1（19C升级/迁移注意事项汇总）、MOS认证查询工具（My Oracle Support Certifications），以及官方Release Schedule文档。把这三个地方的信息对照检查一遍，实际上就把90%的隐性坑给提前排掉了。
1.2 升级路径认证检查清单
动手升级前，我强烈建议先做一张Checklist，把升级路径的每个节点都确认一遍。这份清单是我整理出来，经过多次实际项目打磨的：
| 检查项 | 具体内容 | 验证方式 |
|---|---|---|
| 原库版本确认 | 确认现有版本是11.2.0.4还是12.1.0.2、12.2.0.1等 | SELECT * FROM v$version; |
| 补丁级别检查 | 原库是否已达到该版本的最新PSU/BP | opatch lsinventory |
| 升级路径计算 | 19C是否支持从当前版本直接升级 | 查MOS Doc 1924436.1升级路径矩阵 |
| 操作系统兼容性 | OS版本是否符合19C认证要求 | 查询认证工具中OS/DB版本组合 |
| 字符集兼容性 | AL32UTF8/ZHS16GBK等是否有转换风险 | SELECT * FROM nls_database_parameters; |
| 组件兼容性 | RAC/ASM/Data Guard等组件是否匹配 | SELECT comp_name, version FROM dba_registry; |
| 磁盘空间评估 | 原库空间、目标库安装空间、归档空间 | df -h + 安装包体积核算 |
| 回滚方案就绪 | 是否保留原库可回退的备份 | RMAN全备 + 归档日志备份 |
这里面最容易忽视的是字符集兼容性。我见过一个生产环境，原库是ZHS16GBK，直接跨版本升级到19C时，因为字符集在新版本里出现了映射变化，导致导入的数据出现乱码。虽然官方有一条推荐的转换路径，但很多DBA在规划阶段根本没把这件事写进方案里，最后出了问题只能连夜排查。
1.3 操作系统与第三方组件认证
还有一类容易被无视的认证，是和操作系统、杀毒软件、备份代理等周边工具的兼容性认证。19C对Linux操作系统的版本要求非常严格，比如在RHEL/CentOS 7.6上认证，但在7.4或更低版本上，部分内核参数和依赖包不满足时，安装脚本会直接不通过。这时候不要硬闯，先看Precheck脚本输出，逐个去官网查认证版本和系统补丁。
更要命的是那些装了安全软件的生产机。有次我升级到一半，Data Guard的日志传输进程起不来，后来一查，发现是主机上的安全加固策略把19C需要的端口给禁了。还有杀毒软件实时扫描把oracle二进制文件锁住，导致link过程报错。这类问题根本不会出现在Oracle官方文档里，只能靠自己在测试环境提前模拟排查。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 升级路径选择与准备工作
2.1 三条主流升级路径对比
在决定怎么升级之前，先搞明白路径差异。不同升级路径，牵涉的认证检查和风险点完全不一样。我按实际生产场景，拆成三条主流路径来做对比：
| 升级路径 | 适用场景 | 特点与风险 | 我的评价 |
|---|---|---|---|
| 就地升级（In-Place Upgrade） | 测试环境、升级窗口充足的系统 | 直接在原机运行DBUA或手动sql脚本升级，简单但风险集中，失败回滚时间长 | 适合低负载系统，窗口至少留4-8小时 |
| 导出导入（Data Pump） | 小库/需要清理数据的场景 | 逻辑迁移，灵活但耗时显著，数据一致性依赖停机窗口 | 小于200GB的库可以考虑，大库别这么干 |
| 双系统迁移（Out-of-Place + Data Guard/Switchover） | 生产环境，业务连续性要求高 | 搭建新19C环境后先做Data Guard同步，然后Switchover切换，回滚容易 | 最保险，也是我生产环境的首选方案 |
很多DBA一上来就用DBUA跑就地升级，图省事。但说实话，生产环境我几乎不推荐这种方式。原因很简单：就地升级一旦中途失败，回滚的时间成本和风险太高。而双系统迁移看起来更费事，但每一步都能验证，出了问题随时能切回原库，心理压力和实际安全系数完全不在一个层面。
2.2 环境准备与预检命令
这一小节我直接给干货，按顺序执行一遍，能在升级前发现至少80%的隐患。
先把原库环境的信息收集完整：
bash复制# 检查原库版本和组件信息
sqlplus / as sysdba
SQL> select * from v$version;
SQL> select comp_name, version, status from dba_registry;
# 检查数据库大小，评估迁移时间
SQL> select round(sum(bytes)/1024/1024/1024, 2) as size_gb from dba_data_files;
# 检查归档日志频率，规划日志同步
SQL> archive log list;
新环境准备好后，安装前的预检也用命令跑一遍：
bash复制# 进入解压后的19C安装包目录
./runInstaller -executeSysPrereqs -silent
# 检查Oracle依赖包和系统参数
rpm -q binutils compat-libcap1 compat-libstdc++ gcc gcc-c++ glibc glibc-devel ksh libaio libaio-devel libgcc libstdc++ libstdc++-devel libXext libXtst libX11 libXau libXi make sysstat
# 检查内核参数
sysctl -p
强烈建议先跑一遍-executeSysPrereqs，这个操作一点不浪费时间，它会在真正安装前把操作系统级别的问题全部暴露出来。比如缺依赖包、内核参数不对、进程数限制过小，都会在这里报出来。我自己遇到最多的就是libnsl.so缺失问题，尤其在CentOS 8以上版本，这个包默认不再安装，而Oracle 19C的安装程序还依赖它。
2.3 备份与回滚方案
这里讲一个容易被当成“走形式”的环节——备份。很多DBA觉得有RMAN备份就万事大吉，反正升级失败也能恢复。但真到了升级失败要恢复的时候，恢复时间是否在停机窗口内、归档日志是否完整、控制文件是否能正常恢复，这些全是问题。
我的建议是，升级前不只要做RMAN全备，还要做以下三件事：
- 对原库做一个可读的冷备或克隆。有条件的话，在同一台机器上用
rman duplicate克隆一个临时实例，方便测试直接切换到新环境时出现的问题，不会污染生产环境。 - 保存一份参数文件（
pfile和spfile）和密码文件的副本，升级后所有初始化参数都以它为准来对比变化。 - 记录原库所有关键视图的基线数据，比如
dba_tablespaces、dba_data_files、dba_users、dba_sys_privs，升级后逐项比对，防止权限或存储对象丢失。
升级时最怕的不是技术难题，而是出了问题根本不知道从哪找回去的路径。这三个备选方案，就能确保你在任何情况下都有退路。
3. 19C升级中的核心陷阱拆解
3.1 认证与许可检查陷阱
这一节终于来到标题里提到的“认证陷阱”。我在前面提过，这里的“认证”是广义的兼容性认证，但在实际升级过程中，DBA最容易踩到的是以下三类：
第一类是官方许可/授权检查。Oracle的很多高级功能，如分区、诊断包、调优包，默认是开着的，但你的授权可能并没有购买这些选项。在旧版本里，这些功能即使未授权，也可以正常使用或者只弹警告。但19C升级后，某些功能会直接报错或者不允许使用，原因就是新版本的许可管理变得更加严格。升级前一定要用SELECT * FROM v$option WHERE parameter = 'Partitioning';这类查询确认功能选项，再和技术支持确认授权范围，避免升级后功能被锁或者产生合规风险。
第二类是硬件认证检查。19C在x86-64平台上，对CPU的微码版本、BIOS设置、甚至NUMA架构都有要求。在新硬件上装19C时，如果开启NUMA且未配置numa=off或numa=interleave，有可能出现性能漂移。官方工具Oracle RAT（Real Application Testing）可以提前检测这类问题，但多数人根本没用。
第三类最容易忽视：第三方插件认证。你的数据库IO路径上是否用了存储厂商的CDP复制软件？备份是否用了NetBackup、CommVault？监控是否用了Nagios、Zabbix？这些工具在升级后可能与19C的某些新特性冲突。比如我遇到过一次，存储复制软件在数据库升级后触发快照，导致控制文件出现临时不一致，整整排查了两天。升级前务必把存储、备份、监控工具的版本兼容性一起纳入升级验证计划。
3.2 字符集与数据迁移陷阱
聊到数据迁移，很多人第一反应是Data Pump。但Data Pump不是万能的，尤其当原库是ZHS16GBK或AL32UTF8，而目标库也是AL32UTF8时，其实还算省心。真正麻烦的是一个细节：如果原库中某些表的CLOB列里存了大量非UTF-8内容，导出导入时日志记录会不完整。
我在搜索热词里看到有“oracle 19c impdp 日志记录不完整”这个话题，这确实是我在实操中遇到过的典型问题。具体表现是：impdp日志文件显示任务成功，但对比导出的行数，某几张表明显对不上。这时候十有八九是数据中有特殊格式的字符，或者有损坏的字符编码。处理方式要冷静：
- 先不要轻易重跑导入，而是通过
sqlplus执行SELECT count(*)，从源库逐表核对。 - 检查
impdp日志中是否有ORA-01461（仅能绑定LONG值）或者ORA-01555等关键报错，这些错误往往在日志末尾被遗漏。 - 优先尝试用
CONTENT=DATA_ONLY配合TABLE_EXISTS_ACTION=APPEND补录缺失表，不要整库重新导入。
此外，如果原库是AL32UTF8，而新库意外建成了AL16UTF16等字符集，很多中文内容在迁移后会出现乱码。这里有个原则：除非有明确需求，目标库字符集必须和源库保持一致，或者要走官方支持的字符集转换路径，先转换再导入。千万不要为了图方便，直接跳过字符集校验。
3.3 参数与架构变化陷阱
19C和旧版本相比，有不少隐含参数的默认值发生了变化，还有一部分参数被废弃或者被自动调优取代。这导致升级后最常见的现象就是：升级前SQL跑得飞快，升级后直接走全表扫描。这时候先别急着骂优化器，先把参数差异捋清楚。
我升级时一定会导出一份升级前后参数对比表：
sql复制-- 升级前执行
CREATE TABLE pre_upgrade_params AS SELECT name, value FROM v$parameter;
-- 升级后执行
CREATE TABLE post_upgrade_params AS SELECT name, value FROM v$parameter;
-- 差异对比，类似这样
SELECT p.name, p.value, n.value
FROM pre_upgrade_params p, post_upgrade_params n
WHERE p.name = n.name AND p.value <> n.value;
重点关注的参数包括optimizer_features_enable、optimizer_adaptive_plans、optimizer_adaptive_statistics、_optimizer_use_histograms等。19C起自适应计划默认打开，这在某些场景下会导致执行计划频繁变动。如果业务对稳定性要求极高，可以在升级后先保持optimizer_features_enable为原版本值，等应用压测通过后再逐步放开。这招属于经验技巧，非官方推荐标准做法，但在生产环境中确实能帮不少人平稳过渡。
另外，19C中PGA_AGGREGATE_LIMIT和SGA_TARGET的行为和默认值也变了，如果升级前没有专门调优，默认值可能导致内存分配策略变化。最好在升级前根据当前系统的AWR报告，重新计算一遍内存参数。比如原库SGA 8G，但升级后默认19C自动内存管理可能缩减到更低，造成性能下降。
4. 升级实操全过程记录
4.1 预升级阶段操作步骤
从这一节开始，我带大家把整个升级流程走一遍。以我常用的“双系统迁移”路径为例，这也是生产环境中我最推荐的方式。
预升级阶段主要干四件事：环境准备、参数比对、导出元数据、初始化新库。
第一件事，准备新环境。全新安装一套19C软件，建议安装到和原库独立的位置。安装时用runInstaller图形界面或者静默安装都可以，但静默安装一定要把响应文件里的参数核对好，尤其是ORACLE_BASE、ORACLE_HOME、UNIX_GROUP_NAME。安装完成后，opatch lsinventory确认版本和补丁。
第二件事，收集原库信息并保存基线：
bash复制sqlplus / as sysdba
spool pre_upgrade_check.log
@$ORACLE_HOME/rdbms/admin/utlu112i.sql
spool off;
在老版本下执行utlu112i.sql会生成一份升级预检报告，它会列出升级过程中可能遇到的问题，包括新版本不支持的参数、数据字典中失效对象等。这个报告非常重要，一定要逐行看。
第三件事，用Data Pump只迁移元数据。这里的核心目的是把用户、表结构、存储过程、触发器、函数等对象同步过去。生产库巨大时，不迁移数据，只迁移结构，速度很快：
bash复制impdp directory=DATA_PUMP_DIR dumpfile=schema_meta.dmp logfile=schema_meta.log schemas=SCOTT content=metadata_only
注意，此处如果原库中有公共同义词、DB Link，也需要一并导出。可以在expdp时加上include=SYNONYM、include=DB_LINK等选项。
第四件事，初始化新库并做大对象同步。新库建立后，先不急着打开业务应用，直接把原来库的数据表空间通过Data Guard或者RMAN恢复到新库。我习惯用Data Guard做全量同步，这样业务可以一直运行直到切换那一刻，停机窗口可以压到最短。
4.2 正式切换与升级操作
正式切换是整个过程中最紧张的部分，也是认证陷阱集中爆发的地方。我的切换流程记录如下：
- 业务窗口开始，先停应用，确认数据库无活跃会话。
- 在原库做最后一次日志切换，
alter system switch logfile;，然后确认所有归档日志已传输到新库。 - 在新备库执行
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;，把日志应用完。 - 执行
ALTER DATABASE ACTIVATE STANDBY DATABASE;，将备库转为主库。 - 新库打开，执行
startup，然后跑一遍升级脚本：$ORACLE_HOME/bin/dbupgrade（如果是就地升级，则直接跑catctl.pl）。
这里要提一个关键点：如果走的是“物理备库转化”的方式，在ACTIVATE完成后，还需要手动执行utlrp.sql来重新编译失效对象。19C在备库转主库后，大量视图和包会进入INVALID状态，不重新编译就会出现各种诡异报错。
bash复制sqlplus / as sysdba
@$ORACLE_HOME/rdbms/admin/utlrp.sql
然后是数据字典升级统计信息收集。升级后Oracle建议立刻收集SYS和SYSTEM的固定对象统计信息，否则优化器可能会走极端执行计划。我一般这样操作：
sql复制EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;
EXEC DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;
做完这些，再用一开始导出的参数基线比对新库参数，看看有没有意外变化。如果一切正常，再启动应用联调。
4.3 升级后的验证与测试清单
升级完成不是终点，验证才是决定升级成败的关键。下面是我每次升级后都会执行的验证步骤，照着做能少走很多弯路：
| 验证项 | 操作 | 预期结果 |
|---|---|---|
| 实例状态 | SELECT instance_name, status FROM v$instance; |
OPEN，CONTAINER=NO |
| 监听连通性 | tnsping ORCL19C |
正常返回 |
| 数据库组件 | SELECT comp_name, status FROM dba_registry; |
VALID |
| 失效对象 | SELECT count(*) FROM dba_objects WHERE status='INVALID'; |
数量可控，最好是0 |
| 用户权限比对 | 对比升级前导出的用户权限清单 | 一致 |
| 业务功能冒烟 | 由应用团队跑一遍核心交易链路 | 无报错 |
| 性能基线对比 | 获取新库AWR快照，和原库快照对比 | 核心SQL计划不变或更优 |
如果失效对象数量很大，超过几百个，不要慌。先收集dba_objects中INVALID对象的列表，多半是第三方组件，比如Oracle Text、Spatial、XDB。这时需要单独跑对应组件的升级脚本，比如@$ORACLE_HOME/rdbms/admin/catqm.sql。记住，很多组件升级脚本对执行用户和过程有严格认证要求，一定要确认当前用户是SYS并且以SYSDBA身份操作。
5. 常见问题排查与避坑速查表
5.1 典型问题实录
我把这些年升级过程中最常遇到的问题整理成一份实录，每条都是真实场景，看的人可以直接对照自查。
问题一：升级后应用程序连接报ORA-28040
这个错说的是没有匹配的认证协议。19C默认的认证协议版本比11g、12c要新，旧版本的客户端连不上是常有的事。解决办法有几个：升级客户端到较新版本；或者在服务端sqlnet.ora中配置SQLNET.ALLOWED_LOGON_VERSION_CLIENT=8（这个值要根据实际安全要求来定）。注意，这个参数在11.2.0.4和12c里有不同的写法，配置错了反而会引发新的认证问题。
问题二：执行计划突然异常，SQL性能下降
这个问题很大概率出在19C的adaptive执行计划或者统计信息滞后。处理方式是先看dba_hist_sqlstat和AWR报告，定位是哪些SQL退化了。如果是执行计划退化，可以先用SQL Plan Management把升级前的执行计划固定下来：
sql复制DECLARE
my_plans pls_integer;
BEGIN
my_plans := DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE(
sql_id => 'xxxxx',
plan_hash_value => 1234567890
);
END;
/
这招在升级后阶段非常实用，能快速止血。等业务稳定后，再逐步让优化器重新评估。
问题三：Data Pump导入日志记录不完整
前面已经提到过，这里补充一个具体案例。某次导入一个包含CLOB字段的表，日志文件里显示“xxx rows imported”，但实际目标表只有一半数据。排查后发现问题出在源库的部分CLOB字段里包含\0字符，导致Data Pump在解析时提前截断了记录。处理方式是先清洗源库有问题的数据，再重新导出导入。所以，如果遇到“日志记录不完整”类似报错，第一反应永远是检查数据质量，而不是重跑导入。
问题四：升级过程中ASM磁盘组无法挂载
很多库从文件系统迁到ASM时，会碰见这个问题。19C的ASM在_asm_libraries上有安全加固，旧版本创建的磁盘组在升级后可能需要重新设置compatible.rdbms和compatible.asm参数。我遇到过升级后ASM磁盘组变成MOUNTED状态但无法OPEN的情况，最后是通过ALTER DISKGROUP DATA SET COMPATIBLE.ASM 12.2;解决的。注意，修改兼容性参数前，必须先确认当前ASM和DB版本都高于目标值。
5.2 排查思路与方法论
做DBA这行，遇到问题时，方法比经验更重要。我总结了一套自己的故障排查方法论，在面对升级后各种疑难杂症时很顶用：
- 先看告警日志和追踪文件。
alert_ORCL.log是排查一切问题的起点，先用tail -200看最新报错，再根据报错码进MOS查文档。 - 用数据说话，别猜。比如怀疑性能问题，就先跑AWR、ASH报告；怀疑物化视图过期，就查
dba_mviews.stale；怀疑磁盘空间，就直接df -h。凡是能取到数据的地方，不要拍脑袋下结论。 - 分类归因。把报错按照操作系统、数据库内核、网络、安全性、应用层分成五类，再结合认证矩阵逐类排查，往往能快速圈定问题范围。
- 验证假设时先做最小复现。生产库不能随便试错，可以先在测试环境搭建同版本实例，只导入出现问题的表或用户，复现后再定位。
- 保留现场。出问题时，第一条命令不是重启，而是收集诊断信息，比如
oradebug dump、diagcollect脚本。我见过太多同事一遇到ORA-600就重启数据库，结果重启后信息全没了，只能干瞪眼。
5.3 避坑速查表
把最关键的几条坑整理成速查表，贴在工位上，每次升级前看一遍，能避免大部分低级失误：
| 坑点 | 风险等级 | 应对措施 |
|---|---|---|
| 未检查升级路径认证 | 高 | 用MOS官方路径矩阵校验 |
| 原库补丁过低 | 高 | 先安装推荐补丁集再升级 |
| 未对比升级前参数 | 中 | 保存参数基线并对比 |
| 忽略字符集映射 | 高 | 强制校验目标库字符集 |
| 没有回滚方案 | 极高 | 必须做RMAN全备+冷备 |
| 未审查第三方备份软件兼容性 | 高 | 与厂商确认19C支持版本 |
| 升级后未收集统计信息 | 中 | 执行字典/固定对象统计收集 |
| 错误处理授权选项 | 中 | 用v$option确认功能授权 |
以下这些坑我全都犯过，有的还不止一次。每次想起都觉得如果能提前看一眼这张表，至少能少熬两个通宵。
6. 升级后的安全加固与长期运维
6.1 安全基线与等保合规检查
升级到19C之后，还有一个躲不开的环节：安全合规。现在很多企业都要过等保，数据库层面的安全配置直接影响测评结果。升级后别急着把系统甩给运维，先做一轮安全加固。
先说密码和认证策略。19C默认的PASSWORD_VERIFY_FUNCTION比旧版本严格，但很多迁移过来的用户还是沿用老密码。建议把默认口令安全策略打开：
sql复制ALTER PROFILE DEFAULT LIMIT
FAILED_LOGIN_ATTEMPTS 5
PASSWORD_LIFE_TIME 90
PASSWORD_REUSE_TIME 365
PASSWORD_VERIFY_FUNCTION verify_function_11G;
然后是审计功能。19C默认开启了细粒度审计，但很多DBA会为了省性能把它关掉。等保测评时如果审计没有开启，直接算不合规项。所以建议至少保留AUDIT_TRAIL=DB_EXTENDED，并对敏感操作开启审计，比如：
sql复制AUDIT SELECT, INSERT, UPDATE, DELETE ON SCOTT.EMP BY ACCESS;
AUDIT ADMIN OPTION;
AUDIT CREATE SESSION;
最后是网络层。19C支持TLS 1.2/1.3配置，建议把sqlnet.ora里的加密和完整性校验参数配置上，避免传输层出现明文抓包风险。配置后记得用lsnrctl status检查监听是否正常，防止配错导致所有连接失败。
6.2 日常巡检与长期健康检查
升级不是一锤子买卖。升级完成后，至少要在未来一个月内做密集巡检，确保新版本运行稳定。我的巡检周期是：第1周每天看基线，第2周每两天看一次，之后每周一次。
巡检的核心指标包括：
- 活动会话数和等待事件：如果
DB CPU和User I/O类等待大量增长，多半是有SQL性能退化，需要及时干预。 - 内存使用趋势：用
v$memory_dynamic_components观察SGA/PGA动态调整是否合理。 - 日志报错：定期扫一遍
alert_log和listener.log，提前发现隐患。 - 表空间增长：19C引入了本地管理的临时表空间等新特性，周期内观察临时表空间使用率，防止因排序导致磁盘爆满。
另外，19C是长期支持版本（LTS），Oracle对它的支持时间非常长，适合企业长期稳定运行。但这不代表不需要打补丁，建议每季度评估一次最新的RU（Release Update）和RUR（Release Update Revision），在测试环境验证后再上生产。补丁升级本身也是一套完整流程，涉及opatch、SQL变更，同样要提前读取Release Notes，注意是否有新功能改变默认行为。
做DBA这些年，我的体会是：升级本身只是个动作，真正决定项目成败的是升级前后的检查和保障体系。把认证矩阵、路径选择、备份回滚、参数比对、验证清单这件事做到位，19C升级可以变得非常平稳。第一次做的人别怕慢，前期多花一天仔细预检，后期能为你省下一周甚至一个月的返工时间。希望这篇实操指南能帮大家少走弯路，让每一个夜班都安安静静，不被打扰。