一、PNEWS1360 静默更新说了什么
2026 年 9 月 24 日，Oracle 在没有任何官方公告的情况下，悄悄更新了 My Oracle Support 上的 PNEWS1360（Release Schedule of Current Database Releases，前身 742060.1）。Mike Dietrich 在 10 月 1 日把这个更新点出来之后，整个 Oracle DBA 社区才发现：Oracle AI Database 26ai 在 SPARC Solaris 与 Linux ARM 两个平台上没有发布计划。
把这一段 PNEWS1360 表格里的关键行单独列出来：
- SPARC Solaris：26ai 无发布日期（“not planned”），Oracle DB 19c 在该平台被标为 Terminal Release。
- Linux ARM（aarch64）：26ai 无发布日期；唯一进入 26ai 路线图的 ARM 平台是 Oracle Linux 8.6+ / UEK7 的 aarch64（自 Release Update 23.7 起作为最小支持版本列出，但与主线 SPARC Solaris 不重叠）。
- IBM AIX on Power / IBM Linux on System z / Microsoft Windows：26ai 计划在 CY2027 发布，未给出具体月份。
- Solaris x86 / HP-UX Itanium / 32 位 OS：已被 desupport，不会再有 26ai 数据库或客户端。
这条更新不是一份普通的版本路线图调整。它是 Oracle 第一次公开把"主流 Unix 平台"从主线数据库发行版里踢出去。在过去三十年里，SPARC Solaris 一直是 Oracle 旗舰硬件（Exadata / SPARC SuperCluster）的默认操作系统，也是电信运营商、金融大型机核心系统的常见底座。这一刀下去，受影响的不是"未来选 Oracle 的人"，而是"过去二三十年选 Oracle 的人"。
二、26ai 的真实平台版图
把 2026 年 10 月的 Oracle AI Database 26ai 全平台状态压缩成一份清单：
- GA（唯一首发）：Linux x86-64（Oracle Linux / RHEL），2026 年 1 月。
- 已支持：Linux ARM 仅限 Oracle Linux 8.6+ / UEK7 aarch64（自 23.7 RU 起）。
- 计划 CY2027：Microsoft Windows x64、IBM AIX on Power、IBM Linux on System z——均无具体月份。
- 不发布：SPARC Solaris、Linux ARM 其它发行版。
- 已 desupport：Solaris x86、HP-UX Itanium、32 位 OS——不再有 26ai 数据库或客户端。
Oracle 把 26ai 的发布平台从历史上的十多个收敛到五个左右，且只对其中两个（Linux x86-64 + Linux ARM Oracle Linux）做了承诺。剩下三个还要再等一年多。 对过去三十年习惯了"Oracle 跑在任何一个平台"的大型客户来说，这是一种新的工程现实：Oracle 26ai 实质上是 Linux x86-64 优先，其它平台是补丁。
三、19c “Terminal Release” 的真实含义
Oracle 在文档里把 19c 标为 SPARC Solaris 的 Terminal Release，意思是"这是这个平台上 19c 系列的最后一个版本，不会再有 19c 之后的 19.20、19.21 这种大版本"。但 19c 在 SPARC Solaris 上仍会继续打 Release Update（RU），直到 Premier Support 结束。
Premier Support 时间表：
- Oracle DB 19c Premier Support：延长到 2029 年 12 月（Mike Dietrich 引用 MOS 数据）。
- 19c Extended Support：在 Premier Support 之后开始，至少持续 3 年，需要单独购买。
- 19c Extended Support 之后的 Sustaining Support：仍可拿到补丁，但补丁等级下降，且不含新功能。
把这条时间线画出来：2026 → 2029 三年里，SPARC Solaris 用户还能继续打 RU 维持生产；2029 → 2032 三年里，他们需要付费买 Extended Support 才能继续拿到完整补丁；2032 之后进入 Sustaining Support，等于"自己想办法"。
对仍在线的核心 SPARC Solaris 系统，这是一条清晰但渐进的退出曲线：客户有 3 年免费缓冲期，然后是 3 年付费缓冲期，再之后是未知。这意味着真正的迁移窗口不是现在，是 2026–2029 这三年——任何拖延到这个窗口期之外的项目都会进入"补丁紧张 / 合规风险 / 人才流失"的恶性循环。
四、Data Guard 时延下降：26ai 同步带来的工程红利
如果说 SPARC Solaris 退场是 Oracle 砍掉"老平台"，那么 26ai 的 Data Guard 改进就是 Oracle 给"留下的平台"上的回报。SOUG Day Zurich（2026-10-02）现场记录的数字非常具体：
小型配置
- switchover：19c 76 秒 → 26ai 22 秒（-71%）
- failover：19c 80 秒 → 26ai 15 秒（-81%）
大型配置
- switchover：19c 77 秒 → 26ai 29 秒（-62%）
- failover：19c 94 秒 → 26ai 26 秒（-72%）
把这四个数字平均看，26ai 把 Data Guard 角色切换时延压到了 19c 的 1/3 到 1/4。在电信运营商和金融大型机的双活场景里，这个改进是质变：原来 90 秒的 failover 中断窗口意味着部分前端业务要重试、要做补偿、要发告警；15–26 秒的窗口已经接近很多前端客户端的重试超时，业务可以做到几乎无感。
26ai 在 MAA（Maximum Availability Architecture）层面的改进不只 Data Guard 一项。同期可观测的还有：
- 23ai 引入、26ai 完善的 In-Memory Vector Join 与 In-Memory 文本索引，使 AI Vector Search 与事务负载可以共享同一份内存数据。
- Exadata Exascale 把存储管理从 ASM 推到存储服务器层，I/O 路径进一步缩短。
- Oracle Globally Distributed AI Database 把分片与多区域复制做成产品能力。
把这些改进叠在 19c→26ai 升级里看：26ai 不是"一个版本号升级"，而是"一次架构红利集中兑付"。对 19c → 26ai 升级路径清晰、平台仍然是 Linux x86-64 的客户，这是最直接的收益。
但对 SPARC Solaris 用户来说，这个红利是"看得见、摸不到"——他们要么放弃 26ai 继续在 19c 上运行（拿不到 MAA 改进），要么做一次昂贵的平台迁移（才能拿到改进）。这是 PNEWS1360 这条更新的真正杀伤力：它把 Oracle 给老平台用户的最后一点升级激励也切断了。
五、对仍依赖 SPARC Solaris 的客户意味着什么
在中国，SPARC Solaris / Oracle Exadata 的典型用户是三大运营商的核心计费 / CRM、国有大行的核心交易 / 总账、保险公司的核心承保 / 理赔，以及部分政府央企的核心 ERP。这些系统有几个共同特征：
- 单体应用、不易拆解：很多核心系统是十几年前用
Pro*C/ Oracle Forms 写就的，数据库 schema 复杂、迁移需要重写。 - 业务连续性要求极端：哪怕 RPO=0、RTO=分钟级也嫌长，所以"原地升级"是首选，跨平台迁移基本不被允许。
- 硬件投资巨大：Exadata 一台动辄数千万人民币，五年折旧。
- 人才结构老化：真正懂 SPARC Solaris + Oracle 调优的人正在退休，新人几乎全部在 Linux 上培养。
把这四个特征叠在 PNEWS1360 上看，结论是：未来 3 年里，这些客户必须完成一次"Oracle 19c 在 SPARC Solaris 上原地续命"到"26ai + Linux x86-64"的跨平台迁移。延迟到 2029 年之后会同时面临补丁风险（RU 修复等级下降、严重 CVE 修复延迟）、合规风险（等保 / 金融监管对 Premier Support 状态敏感）、人才风险（懂 SPARC + Exadata 的工程师供给持续下降）、生态风险（OEM / AWR / Data Guard broker 对 19c 的新功能支持逐步冻结）。
六、迁移路径的三种现实选择
对仍在线的 SPARC Solaris + 19c 客户，现实路径只有三条：
路径 A：同平台原地升级到 26ai（不可行）。 Oracle 不会为 SPARC Solaris 发布 26ai，所以这条路在物理上走不通。
路径 B：跨平台升级到 26ai on Linux x86-64（主流选择）。 把数据库从 SPARC Solaris 迁移到 Linux x86-64（通常落在 Exadata X10M 或同等 x86 服务器上），同时做 19c → 26ai 升级。这是 Oracle 官方推荐路径。工程上需注意：SPARC 是 big-endian、x86-64 是 little-endian，不能直接用跨平台 Data Guard standby，必须用 expdp/impdp 或 GoldenGate 做跨平台数据搬运；19c → 26ai 推荐用 AutoUpgrade 走 Out-of-Place Upgrade，已有多篇公开文档（Mike Dietrich / Alex Sanz）描述 19c 非 CDB → 26ai PDB 的 refreshable clone PDB 路径；Pro*C 应用需重新编译，Forms/Reports 与第三方 ISV 应用需要逐一与厂商对齐 26ai 兼容性。
路径 C：替换为非 Oracle 数据库（部分场景适用）。 对部分新业务、不涉及核心账务的系统，可以直接跳过 Oracle、用国产数据库或 Postgres 系替代；对核心账务系统则风险太大，短期内不会被采纳。
这三条路径里，B 是绝大多数 SPARC Solaris 用户的唯一选择。工程预算通常是数据库采购价的 2–3 倍，时间窗口 12–24 个月。
七、国产数据库的承接机会
PNEWS1360 的更新对国产数据库厂商来说是一个明确的窗口期。窗口的核心不在于"Oracle 让出了多少市场"——而是"哪些客户必须做决策、并且决策时点上愿意听国产方案"。
具体来说，国产数据库厂商可以重点跟踪三类客户：
- 类型一：仍在 Oracle 11g / 12c 上的非 SPARC Solaris 用户。 11.2.0.4 / 12.1.0.2 / 12.2.0.1 的升级支持 2026 年底结束，PNEWS1360 给他们的信号是"Oracle 也在加速平台收敛，正好可以一起决策"。
- 类型二：SPARC Solaris / Exadata 上的 19c 用户。 迁移窗口期 2026–2029，三年内必须决策。国产数据库厂商可与 ISV 联合，针对
Pro*C/ Forms 给出兼容方案，让客户一次评审迁移 + 国产化。 - 类型三：原计划在 SPARC Solaris 上等 26ai 的新项目。 几乎只能转 Linux x86-64 + 26ai，或直接评估国产数据库。
对国产数据库来说，可借鉴的工程方向有四个：① 把 SPARC Solaris → Linux x86-64 的兼容性工具链做到"开箱即用"；② 兼容 Pro*C / Forms 存量代码（金融核心系统替换最硬门槛）；③ 拿出对等的"切换时延 / 故障恢复时延"对比基准（Data Guard 76s→22s 是强信号）；④ 把"迁移服务"做成产品的一部分（参考 AutoUpgrade + Data Guard 跨平台 + MOS Note 的标准化路径）。
八、给 DBA 与架构师的结论
PNEWS1360 这条更新给国产数据库生态传递了三条工程信号：
信号一：Unix 时代正式结束。 Oracle 把 26ai 收敛到 Linux x86-64 + Linux ARM 的双平台，是大型数据库厂商第一次正式承认"Unix 平台已经不值得继续投入"。任何仍把"Unix + Oracle"作为长期规划的系统，都需要在 2026–2029 三年内重新评估。
信号二：26ai 的红利是真的，但要求升级路径同样完整。 Data Guard 时延 1/3 到 1/4 的下降是真实改进，获得条件是"客户必须在 2026–2029 完成跨平台迁移"。对没有这条迁移能力的客户，26ai 的所有改进都等于不存在。
信号三：窗口期比想象的短。 2026–2029 是决策窗口、2030–2032 是执行窗口、2032 之后是不确定窗口。
对个人 DBA / 架构师：SPARC Solaris / Exadata 用户立刻把"2029 前完成迁移"作为不可推迟目标；评估"是否继续 Oracle"的客户把 PNEWS1360 作为关键决策输入之一；做国产数据库迁移方案的厂商把"SPARC Solaris / 19c 用户"作为明确客户画像，把 Pro*C 兼容、跨平台数据搬运、切换时延纳入产品能力地图。PNEWS1360 这一刀，是 Oracle 给过去三十年最大的一次战略转向。窗口期已经打开，剩下的就是行动速度。
参考链接
- Mike Dietrich — Oracle AI Database 26ai isn’t planned for SPARC Solaris and Linux ARM
- PNEWS1360 — Release Schedule of Current Database Releases（MOS）
- dbi-services — SOUG Day October 2026（Data Guard 改进数字）
- database-blog.at — Oracle Datenbank Release Schedule Update August 2026
- Oracle Lifetime Support Policy for Technology Products
