Oracle 多云战略加速：跨云互联 GA、Exascale 数据库与区域扩张的产业含义

Oracle 多云战略加速：跨云互联 GA、Exascale 数据库与区域扩张的产业含义

导语

2026 年 5 月至 8 月，Oracle 在其官方多云博客上连续披露了一系列进展：Oracle Interconnect for AWS 由限量可用转为正式可用（GA），Oracle AI Database@AWS 与 Oracle AI Database@Google Cloud 分别引入 Exascale 基础设施与 Exadata Exascale 存储能力，同时区域覆盖扩展至全球 22 个。这批更新看似分散，实则指向同一命题：当企业工作负载天然分布在多个云上，被视为最难搬迁的数据库资产，能否在不重构应用的前提下跨云运行？对 CTO 与云架构师而言，这直接关系到跨云网络的成本结构、数据库部署模式，以及数据驻留与业务连续性的实现路径。

一、事件背景：一次跨越三个月的集中推进

Oracle 多云的核心思路并不复杂：把 Oracle Database 服务运行在部署于其他云区域附近的 OCI 基础设施上，通过熟悉的工具链与合并账单交付给客户。2026 年夏季的这批公告，是这一思路在能力与地理两个维度上的同步扩张。

| 时间 | 事件 | 要点 | | --- | --- | --- | | 5 月 15 日 | Oracle Interconnect for AWS 限量可用 | 由 OCI 产品管理高级副总裁 Nathan Thomas 宣布，目标是用托管连接替代客户自建跨云网络 | | 5 月 20 日 | OCI GoldenGate 在 Oracle AI Database@Google Cloud 上 GA | 可在 Google Cloud 控制台直接开通，并使用 Google Cloud 承诺抵扣付费 | | 5 月 20 日 | Oracle AI Database@AWS 落地圣保罗 | 覆盖南美市场，初始一个可用区 | | 6 月 17 日 | Oracle AI Database@AWS 上线一周年 | 宣布 Autonomous AI Database Serverless GA、Exascale 基础设施即将上线、扩展至 20 个 AWS 区域、MAA Platinum 层级，以及长期战略合作协议（SCA） | | 6 月 23 日 | 新增斯德哥尔摩与圣何塞 | 全球区域总数达到 22 个 | | 7 月 29 日 | Oracle Interconnect for AWS 正式可用 | 首批落地 OCI Ashburn 与 AWS 美东（北弗吉尼亚），更多区域对后续推出 | | 8 月 12 日 | ExaDB-XS 在 Oracle AI Database@AWS 上线 | 按 ECPU 与存储用量计费，降低入门成本，通过 AWS Marketplace 售卖 | | 8 月 14 日 | Exadata Exascale 进入 Oracle AI Database@Google Cloud | 客户可开通带 Exascale 存储的 Exadata VM 集群 |

值得注意的是，本轮披露集中在 AWS 与 Google Cloud 两端。这种先与部分超大规模云厂商深度绑定的节奏，说明 Oracle 的多云策略更接近能力复制而非全面铺开。

二、技术解析：三件事分别解决什么问题

1. 跨云互联：把网络从项目变成服务

在多云早期，连接两个云的方式主要有两种：让流量走公网，或自建加密隧道。前者在安全、可用性和容量上都有明显暴露面；后者虽然把公网排除在外，却把采购、配置和容量管理的负担全部压给客户。实践中，企业还要同时协调两套并不为彼此设计的路由模型、管理两边的第三方合同，并在真正开始业务之前先搭好一套自建网络。

Oracle Interconnect for AWS 试图改变的正是这一层。它提供 OCI 与 AWS 之间私有、高速、全托管的连接，默认使用 IEEE 802.1AE MACsec 加密，采用 OCI 统一且全球一致的连接定价，不收取数据传输费用，并由 Oracle 与 AWS 双方协同支持。用非技术语言解释：这相当于在两个园区之间修了一条专线高速，由两家共同运营，企业不再需要自己铺路、自己买地、自己维护路面。

2. Exascale：解耦计算与存储，压低 Exadata 的入场门槛

传统 Exadata 更像一体化设备：计算与存储按固定比例捆绑扩容，容量规划一旦偏差，要么浪费，要么受限。Exascale 的关键变化是把两者拆开。

在 AWS 侧，ExaDB-XS 基于 Oracle 的多租户弹性云模型，客户可以从小规模 VM 集群起步，独立扩展计算与存储，只为实际使用的 ECPU 和存储付费，同时支持 Oracle Database 19c 与 Oracle AI Database 26ai，并提供 thin clone 与基于 redirect-on-write 的快照与克隆能力。在 Google Cloud 侧，客户则可开通带 Exascale 存储的 Exadata VM 集群，随数据库需求增长灵活扩展存储，同时保留专用 Exadata 的性能、可用性与可靠性特征。

对管理者而言，这一变化的实质是采购逻辑的转变：从一次性买足容量转向按需付费、按增长扩容，资本支出属性被更多推向运营支出。

3. OCI GoldenGate：多云场景下的数据平面

跨云运行数据库，绕不开数据同步。OCI GoldenGate 在 Google Cloud 上正式可用后，客户可直接在 Google Cloud 控制台开通这一托管服务，并以 Google Cloud 承诺支付。它提供低延迟的变更数据捕获（CDC）与实时复制，支撑低风险数据库迁移、混合与多云架构、可用性提升，以及跨 Oracle 与非 Oracle 数据源的近实时分析。

CDC 可以理解为一张持续更新的变更流水账：源库每一次数据改动都会被捕获并同步到目标端，而不是等批处理窗口统一搬运。这让运营、分析与 AI 负载都能建立在持续同步的数据之上。

三、企业影响分析

成本结构。 ExaDB-XS 按 ECPU 与存储用量计费，直接降低了 Exadata 的试用与起步门槛；Exascale 的独立扩容减少了为峰值预留容量的浪费。Interconnect 采用统一连接定价且不收取数据传输费用，使跨云网络支出更接近可预测的固定项。需要提醒的是，跨云总成本仍要结合两端的计费规则综合测算，网络只是其中一环。

部署模式。 对已经在 AWS 上运行应用的 Oracle 客户，不重构是这批更新的核心卖点：数据库服务在 OCI 基础设施上运行，却与 AWS 应用就近部署。分阶段迁移、分布式应用架构、减少对公网依赖，都是可直接落地的场景。

运维与支持。 合并账单、沿用既有工具链以及 Oracle 与 AWS 的协同支持接口，降低了跨云团队的组织摩擦。但多云运维的复杂度并不会因此消失，它只是从自建网络与合同管理，转移到联邦式身份、监控与故障定位。

安全与合规。 默认 MACsec 加密与私有链路减少了公网暴露面。区域扩张则是合规议题的直接回应：斯德哥尔摩服务北欧及欧洲市场的数据驻留需求，圣何塞贴近美国西部的技术与业务集群，圣保罗覆盖南美市场。对受监管行业而言，这类区域选择往往比性能指标更具决策权重。

四、市场竞争分析

从竞争格局看，这批更新最大的特点是错位竞争。Oracle 没有在 IaaS 层与超大规模云厂商正面争夺通用算力，而是把数据库当作跨云交付的产品，让 AWS 与 Google Cloud 获得更多工作负载，自己获得数据库消费。这更像一种互补型结盟：6 月 17 日双方宣布的长期战略合作协议（SCA）进一步固化了这层关系。官方披露，Oracle AI Database@AWS 上线一年后已有数百家客户在其上运行关键业务负载。

可能受益的一方包括：拥有大量 Oracle 数据库资产、但希望把应用保留在其他云上的企业客户；AWS 与 Google Cloud，因为承载了更多企业级数据库与 AI 工作负载；以及围绕 AWS Marketplace 与 Google Cloud 承诺预算运作的渠道与集成商。

可能承压的一方包括：以自建跨云专线与网络托管为主业的第三方服务商，其价值主张被托管连接加统一计价稀释；以及业务数据库必须整体重写为云原生数据库的叙事——Exascale 与 19c/26ai 双版本支持让更多企业可以选择先搬迁、后现代化的渐进路线。相应地，云原生数据库厂商在争取 Oracle 存量工作负载时，面对的替代阻力也会上升。

五、行业趋势观察

多云的竞争焦点正从连接转向数据平面。 过去几年，多云的工程问题主要是网络互通；而 Exascale、GoldenGate、原生 AI 向量搜索这些能力表明，下一阶段的竞争发生在数据如何跨云流动、如何被 AI 使用上。

数据引力的方向发生反转。 传统做法是把应用搬到数据旁边，现在则是把数据库服务搬到应用旁边——数据库运行在 OCI 基础设施上，却部署在靠近 AWS 或 Google Cloud 区域的位置。这种云中的云模式，可能成为企业级遗留系统的默认迁移路径。

主权与区域化成为产品特性。 斯德哥尔摩、圣保罗、圣何塞的相继落地说明，区域覆盖不再只是延迟优化，而是数据驻留与业务连续性的合规基础设施。

AI 与数据库的边界持续模糊。 从产品命名到能力组合（Autonomous AI Lakehouse、原生 AI 向量搜索、26ai 版本），Oracle 正在把 AI 能力内置到数据库层，而不是让企业在数据库之外另建一套向量检索与特征平台。

这些变化共同指向一个判断：多云正在从网络架构选择演变为数据架构选择，未来五年的云基础设施竞争，将更多围绕数据服务的可移植性展开。

CloudTechDaily Insight

这批公告最值得记录的，不是某一个功能点，而是多云竞争的计价单位正在改变。过去企业评估多云，看的是专线带宽、出口流量与运维人力；现在被摆上台面的，是数据库的入门成本（按 ECPU 与存储计费）、跨云连接的计价方式（统一连接定价、不收数据传输费），以及数据能否就地被 AI 消费。当这些要素被产品化，多云决策就从技术可行性问题，变成了财务与合规的可计算问题。

对企业 IT 战略而言，有三点值得纳入评估。第一，跨云数据库不再是迁移项目的终点，而可以成为长期运行状态，架构评审的口径需要相应调整。第二，连接层被托管化之后，跨云成本的可预测性提升，但依赖也随之加深——客户需要评估对两家长周期协作关系与联合支持流程的依赖程度。第三，区域扩张带来的是合规选项而非单纯的性能收益，受监管行业应把区域清单纳入数据驻留与连续性规划。

必须承认的是，这一模式仍取决于超大规模云厂商的合作意愿与产品路线图。本轮披露集中于 AWS 与 Google Cloud，覆盖面尚不完整；联合支持在故障定位与责任划分上的实际表现，也需要更多生产环境验证。因此更务实的做法是：以 ExaDB-XS 的小规模集群验证关键业务数据库在跨云环境下的性能与运维体验，用 Interconnect 试点替代现有跨云公网或自建链路，并在扩大规模前完成成本模型与数据驻留的双重核对。

从中长期看，数据库作为跨云服务很可能像当年的托管数据库一样，从特例变成行业默认配置。一旦头部数据库厂商完成这一步，其他企业与云厂商的跟进压力将迅速显现——这才是本次事件对云计算产业最深远的影响。

---

参考来源：Oracle 官方博客《Oracle Multicloud – What's News》，https://blogs.oracle.com/cloud-infrastructure/oracle-multicloud-whats-new-blog