Oracle 数据库升级怎么选？先把时间表算清本文导读：Oracle 数据库升级的选型，本质是在算时间表。19c 的免

Oracle 数据库升级怎么选？

先把时间表算清

本文导读

：Oracle 数据库升级的选型，本质是在算时间表。19c 的免费补丁能拿到 2029 年底，26ai 才是下一站长支持版，RAC 补丁升级节奏也要一起排。一篇讲清怎么倒排。

开篇

10 月最后一个工作日 16:40，年度规划评审会开到第三轮，分管领导把预算表往前一推，问了一句：

机房里那七八套 Oracle 数据库升级，明年到底怎么排？

11g 那两套是先到 19c，还是一步跳到 26ai？去年刚上的 19c 那套，还能安安稳稳跑几年？

这个问题没法当场拍脑袋回答，因为它根本不是技术题，是算术题。

Oracle 数据库升级的难点至少有三层：1）版本名单本身就乱，19c、21c、23ai、26ai 听着像一家子，角色完全不同；2）支持期口径复杂，高级支持、扩展支持、要不要额外付费，一个数字看漏，整张计划就偏了；3）升级路径有硬约束，不是想从谁直接升到谁都行。

这一篇把账算清：长支持版和创新版到底差在哪、19c 与 26ai 两张时间表怎么叠加、升级路径怎么倒排。

读完能带走一张版本站位分叉图，规划会上直接用。

一、选型三个误区：先想清楚升级的终点在哪

上个月评审会的现场顺序是：先让人把每套库的版本和补丁基线报出来，再对着官方文档逐套对位。

结论先说，三套库里有两套的规划方向一开始就是偏的。

误区一：把创新版当升级终点。

21c 的错误修正在 2027 年 7 月 31 日就截止，而且没有扩展支持；18c 更是 2021 年年中就停了。创新版是官方用来"路过"的，不是用来"住下"的，规划里把它写成目标版本，等于给未来埋雷。

误区二：只看高级支持到期日，不看扩展支持要不要花钱。

19c 的补丁在 2029 年 12 月 31 日之前不需要额外付费；之后想继续拿错误修正，要走付费的扩展支持，到 2032 年 12 月 31 日。预算没批，这张时间表就是另一回事了。

误区三：把 26ai 想成一次伤筋动骨的大版本迁移。

官方 FAQ 的口径很明确：23ai 只要把 2025 年 10 月的 RU 应用上，就直接成为 26ai，不需要数据库升级、也不需要应用重新认证。真正的大动作只有 19c 到 26ai 这一段。

二、时间表拆解：长支持版的账本与三个高频坑

先弄懂 Oracle 的版本模型：

创新版与长支持版交替发布，长支持版才是生产环境的落点。

官方对长支持版的口径是五年高级支持加三年扩展支持；19c 是上一任，26ai 是现任。动手排期之前，先看清自己站在哪张时间表上：

-- 看清当前版本（版本号读法：19.24.0.0.250121（示例值）前几段是版本，末 6 位是日期）

select banner_full from v$version;

-- 数据字典里看已应用的 RU，这是升级预算的真实起点

select action_time, patch_id, action, status, description

from dba_registry_sqlpatch

order by action_time;

-- 补丁层面的账，RAC 两个节点都要看，编号必须一致

-- $ORACLE_HOME/OPatch/opatch lspatches

坑一：路径没规划就立项。

官方升级路径只留了两条主线：19c 或 21c 到 26ai，其余版本必须先到这两站。Oracle 11g 升级 19c 这一段本身就是独立工程，跨版本、跨字符集、跨应用认证，把它当成 26ai 项目里"顺手做掉的一小步"来排期，工期翻车几乎是必然的。

坑二：把补丁节奏和升级项目搅在一起。

19c 和 26ai 都是每季度发一个 RU，Oracle 补丁 PSU RU 怎么打属于稳态运维；Oracle 数据库升级是项目制。两套节奏共用同一个变更窗口时最容易打架——季度 RU 给升级项目让路可以，反过来让补丁停摆等立项，安全风险会一路累积。

坑三：按上线年份倒推支持期。

"五年高级支持加三年扩展支持"是从版本发布起算的，不是从你上线那天起算。

接手别人留下的库，别翻采购合同，翻数据字典

——上面的查询结果加上官方时间表，剩下的年限才是真实预算。

三、实操：把 Oracle 数据库升级排成一张时间表

规划会的讨论要有抓手，

先把版本站位对照表拍在桌上，再逐套对号入座

版本

角色

修正/补丁止日

给运维的一句话

19c

长支持版（上一任）

高级支持止 2029-12-31；付费扩展支持止 2032-12-31

现在的底盘，季度 RU 照跟

21c

创新版

修正止 2027-07-31，无扩展支持

停更倒计时已开始，别再往里放新系统

23ai

创新版

应用 2025-10 RU 即达 26ai

过渡跳板，不是落点

26ai

长支持版（现任）

高级支持止 2031-12-31，扩展止日以官方公布为准

下一站，路径只认 19c 与 21c

对完表，倒排只要三步。

每一步都写进规划文档，日期口径统一标"以 MOS 742060.1 与 Lifetime Support Policy 最新版为准"。

1.

盘现状：每套库记下版本、当前 RU、业务权重，RAC 环境逐节点核对补丁编号。

2.

定站位：按第四节的分叉图对号——19c 的在 2029 年底前定去留，23ai 的走 RU 过渡，11g/12c 的先排 19c 项目，21c 的进搬迁队列。

3.

错峰排窗口：季度 RU 照打，大版本升级按年度立项，两类变更不抢同一个窗口。

四、风险提醒与预防清单 ★

时间表是规划文件，不是承诺书。

Oracle 数据库升级项目立项前，必须回到 MOS 742060.1 与 Lifetime Support Policy 手册核对最新口径

，本文的日期只代表写稿时的公开信息。另外提醒一句：升级项目的验收别只看"能跑起来"，升级后性能下降怎么归因，靠的是升级前留好的基线，不是事后拍脑袋。

预防清单四条，规划文档里逐条对照：

每季度 RU 照打

：长支持版的补丁按季度发，落后两个季度以上，升级项目的历史包袱就会明显变重。

RAC 补丁升级保持两节点同基线

：补丁编号不一致，故障排查时会多出一堆假象，先对齐再谈别的。

升级验收带性能基线

：上线前留一份 AWR 基线，验收对比有据可查。

日期以官方文档为准

：本文所有时间点立项前都要重新核对一遍。

全文总结

1.

Oracle 数据库升级的选型本质是算时间表：长支持版是落点，创新版只是路过。

2.

19c 的免费补丁止于 2029 年底，付费扩展支持到 2032 年底；26ai 高级支持到 2031 年底，是下一站，路径只认 19c 与 21c。

3.

季度 RU 照打、大版本升级错峰立项，所有日期以官方文档最新口径为准。

把这张版本站位分叉图转给正在做明年规划的同僚

，能少吵一轮会。