当前位置：首页 > news >正文

Oracle 数据库在海光平台上运行表现如何？附兼容性验证、性能优化与迁移实践

news 2025/10/11 9:24:03

在近期研讨会中，SmartX 技术专家钟锦锌分享了基于 SmartX 超融合信创平台（海光）运行 Oracle 数据库的兼容性验证、性能优化探索及跨平台迁移实践，为企业基础设施信创转型提供思路与参考。

重点结论

兼容性：在海光平台下分别验证 Oracle 单库以及 ADG 数据库集群均可稳定运行。
性能优化：启用 Boost 模式后，Oracle 在海光平台的性能提升 50%~98%；在集群缓存不足的情况下，启用常驻缓存后，相比缓存击穿的情况下数据加载时间缩短 67%，整体性能提升 118%。
跨平台迁移：利用超融合跨集群冷迁移功能，可实现 Oracle 虚拟机在 Intel/Hygon 平台间互相迁移；通过 ADG 集群可实现 Intel/Hygon 数据库主备复制。
同等配置下，在海光平台运行 Oracle 数据库可达到 x86 环境的 60%-70%。

点击链接，即可观看研讨会回放视频。

下载《SmartX 产品在数据库场景下的测试与实践合集》，了解更多数据库场景性能评测与探索实践！

（以下为根据视频整理的文字内容）

背景介绍

当下， “信创改造” 已经成为企业 IT 架构转型过程中的共识。信创落地范围已经从早期的 “2+8” 行业向更广泛的 “2+8+N” 类行业扩展，信创改造也正全面加速，信创改造的覆盖面和硬件市场规模日益扩大，标志着信创改造的第一步顺利完成。

当企业部署了信创硬件之后，更重要的任务是将现有的 IT 业务系统迁移到这些新平台上。企业通常有两种选择：

一是重构式改造：即基于信创软、硬件生态，重新开发应用系统，构建全栈信创的改造方案。这种方案虽然最彻底，但存在改造成本高、开发周期长以及维护困难等问题。
二是跨硬件平台的应用迁移：即在不改变现有业务逻辑的前提下，将当前系统整体迁移至兼容的信创硬件上运行。相比业务重构的方式，这种方式无需对应用重新开发，成本低、周期短，更加适用于规模化业务系统的信创改造。

现实中，企业用户更希望结合两种改造方案优势：将大部分现有业务系统通过迁移的方式进行信创改造，尽可能消除业务侧运行风险；而对于符合条件的新业务系统，则基于信创生态全新开发。双轨并行，逐步实现全栈信创的目标。

在数据库系统的信创改造上，可以采用同样的思路：将部分现存的业务系统数据库系统整体迁移至信创硬件上运行，避免应用改造，快速实现生产业务的整体迁移。其中，Oracle 数据库的迁移是不少用户都很关注的方案，尤其是 Oracle 数据库在信创硬件平台上的性能、可靠性以及迁移相关事项。

基于此，SmartX 将重点验证这一方案的可行性：在不触动业务系统的情况下，将运行于 Intel x86 服务器上的 Oracle 数据库迁移至基于海光芯片的平台，并对数据库的兼容性、性能表现以及生态支持等多个方面进行验证，确保迁移方案符合生产业务的基本需求。验证时我们将重点关注用户普遍存在的一些顾虑：

Oracle 在海光平台上运行是否存在兼容性问题？
数据库性能是否会出现明显下降？
迁移过程有哪些注意事项或风险点？
是否有相应的优化手段保障运行效率？

测试项目

Oracle 数据库与基于海光平台多个国产操作系统的兼容性
如何基于海光平台优化 Oracle 数据库性能
Oracle 数据库从 x86 平台迁移至海光平台的方案可行性

硬件与测试环境

本次测试在两套超融合集群环境下进行：一套是基于海光二号处理器的服务器（3 台）组成，另外一套集群是基于 Intel x86 服务器（3 台）组成。共计 6 台服务器用于对比测试，具体配置如下图所示。

兼容性验证

SmartX 团队选取了 5 个常见版本的 Linux 操作系统进行部署测试。其中，Red Hat Enterprise Linux 7.9、Kylin V10 SP3 和 SUSE Linux Enterprise 15 SP6 三款操作系统能够正确识别海光 CPU，并正常完成安装和运行 Oracle 19c 数据库。

从测试结果可以看到：Oracle 19c 数据库在海光芯片上运行，对于操作系统的要求相对 Intel 芯片更加严格；Linux 内核版本较低容易导致安装失败，建议使用 Red Hat Linux/CentOS 7.9 或以上版本。

基于海光芯片的性能优化措施

在完成 Oracle 数据库在海光平台上的兼容性验证后，我们进一步探索了性能优化措施，具体从物理主机与集群层面的优化和虚拟机层面的优化两部分展开。

物理主机与集群层面的优化措施

1. 开启 BIOS 性能模式

海光 CPU 默认处于节能模式，易导致 CPU 主频动态降低，影响数据库实时响应能力。建议在 BIOS 中将电源策略设置为“Performance”（性能模式），防止降频运行带来的性能衰减。

2. CPU 选型建议

Oracle 数据库既需要良好的多核并行能力，也对单核主频依赖较高。因此在选择海光 CPU 时，需重点关注以下三项指标：

主频：Oracle 单线程操作依赖高主频以降低延迟，建议使用至少 2.0Ghz 主频的 CPU。
核心数：Oracle 数据库对多核并行处理能力敏感，建议配置双路处理器，且每路具有 12 个或以上核心。
L3 缓存容量：对于访问内存的效率影响大，建议选择拥有更大 L3 cache 容量的 CPU。

实测显示，海光 7390（2.7GHz，256MB L3 缓存）相比 7285（2.0GHz，128MB L3 缓存）在 Oracle 数据库的 TPC-C 压测中性能平均提升 14.38%，最高性能差距可达 28%。

3. 物理主机性能对比测试

在裸金属测试中，海光 7390 的事务处理能力及内存带宽均优于同系列的 7285 与 5380：

与 7285 相比，CPU 性能提升约 30%。
与 5380 相比，差距更为明显，不建议将数据库部署于海光 5 系列 CPU 上。

4. 高性能 SSD 带来性能提升

实际客户案例表明，采用 NVMe SSD 作为缓存层，性能提升显著。在数据库简单场景中，跑批时间可以缩短 85%；在复杂场景中，跑批时间可以缩短 82%。因此，我们建议在数据库业务场景下优先采用 NVMe SSD 构建缓存层。

5. 启用 Boost 模式

SmartX 超融合的 Boost 模式通过将计算与存储功能部署在同一台主机，打通虚拟机内存与存储引擎内存的数据通路，实现 I/O 请求的“零拷贝”路径，加速存储访问性能。通过实测，使用 Boost 模式后，随机读 IOPS 提升超 4 倍，延迟降低 80%；随机写 IOPS 提升 1.9 倍，延迟降低 48%。

此外，启用 Boost 模式后，数据库性能提升同样明显，提升比例在 50%~98% 之间。

6. RDMA 存储网络优化

启用 RDMA 网络协议有助于进一步减少分布式存储软件中的网络延时，并提升带宽。启用 RDMA 以来，我们对比了顺序读和顺序写的性能，发现数据库在分布式存储环境下的顺序写带宽提升高 38%，有助于解决高并发写入性能瓶颈。

虚拟机层面的优化措施

我们还探索了在虚拟机及虚拟化配置层面进一步提升 Oracle 数据库在海光平台运行效率的方案。

1. 虚拟磁盘优化

分卷存储不同功能文件：建议将数据库的不同类型文件（如 Oracle 日志卷、数据库数据文件卷等）分布在独立的虚拟卷中，以提高 I/O 并发能力；
选择高性能虚拟磁盘总线：推荐使用 Virtio 虚拟磁盘总线，相较 SCSI 虚拟总线，性能提升约 9.7%。

2. 虚拟网卡优化

我们对比测试了 SR-IOV 直通网卡和默认的 Virtio 虚拟网卡在数据库压测下的性能表现。从测试数据来看，在所有测试场景中，SR-IOV 的性能都优于 Virtio。

不过，在并发数比较低的时候，两者的性能差距并不明显；随着并发的增加，差距会逐渐拉大，SR-IOV 的性能最高可以领先 42%。另外，在同样的 Warehouse 规模下，使用 SR-IOV 时性能波动更小，表现更稳定。基于这些结果，我们的建议是：

对于一般的数据库业务：可以直接使用 Virtio 虚拟网卡，配置灵活、硬件成本低；
对于性能要求极高的数据库：尤其是需要部署数据库集群的场景，可以考虑采用 SR-IOV 直通网卡，以显著提升网络性能。

3. 常驻缓存

我们再来看 SmartX 超融合的另一个特色功能——常驻缓存。在分层存储架构中，当集群缓存空间不足，或者数据变冷并下刷到机械盘、低性能盘的情况下，业务请求需要重新访问这些数据，就可能发生缓存击穿（部分数据无法在缓存层命中，导致 I/O 访问延时增大），数据库的 I/O 性能将受到严重影响。常驻缓存功能可以针对某个虚拟机，甚至某个虚拟卷进行设置，把其中的数据持久化固定在缓存层，确保数据不会被交换至容量层，从而保证关键虚机或关键数据库始终在缓存中运行，性能更有保障。

我们基于 Swingbench 对比了两种情况严重击穿和启用常驻缓存情况下的性能差异：

启用常驻缓存时，数据库载入阶段 I/O 吞吐可达 2 万 IOPS，且始终维持较高吞吐；
击穿情况下，性能只有峰值的 1/10，差距非常明显。

再通过数据库的 TPS 实际性能评估严重击穿和启用常住缓存后的不同表现：

击穿场景下，TPS 在加载初期一直很低，直到数据被加载到内存才逐步提升；
启用常驻缓存后，TPS 从一开始就保持高水平，数据加载时间缩短 67%，整体性能提升 118%。

因此，对于在 SmartX 平台上承载的关键数据库，我们建议开启常驻缓存，以确保 I/O 性能的稳定与高效。

4. CPU 与内存绑定（NUMA 优化）

接下来我们关注到 CPU 的 NUMA 差异。通过对比 Intel 和海光的 NUMA Node，发现二者存在明显差异。

Intel CPU：结构相对简单。每个处理器仅包含一个 NUMA 节点，所有核心访问本节点内存的延迟相同，只有在跨节点访问（如 Node0 访问 Node1 内存）时，延迟才会增加。此外，Intel 的每个 NUMA 节点可直接访问整机 50% 的内存资源。
海光 CPU：结构更为复杂。单个 CPU 内含四个 NUMA 节点，每个节点对应一定数量的核心及一组内存资源。由于 NUMA 节点数量多，远程访问的概率也更高。在均匀分布情况下，每个 NUMA 节点仅拥有全机 12% 的内存，远低于Intel 架构。

这两种结构差异也会对数据库性能带来影响。其中，两者本地访问内存的延迟均约为 80ns，Intel 跨节点访问延迟约为 130ns，而海光可达到 160ns；同时，跨节点还会带来 30%～60% 的内存带宽损失。因此，尽可能避免跨 NUMA 节点访问是提升性能的关键。在实际部署中，vCPU 动态分配、超出单节点核心数和内存分配超限均容易引发跨 NUMA 访问。

鉴于海光 NUMA 结构复杂，其对 NUMA 绑定的依赖程度远高于Intel 。因此我们建议：

在允许的情况下启用 NUMA 绑定，并尽量将虚拟机的全部 vCPU 固定在同一节点中；
当确需使用大量核心时，优先保证 vCPU 位于同一 CPU 插槽，以缩短节点访问距离。内存分配时也应尽量避免超出单节点可用内存上限。

实际测试表明，在 SmartX 集群中为 Oracle 数据库开启 CPU 独占后，整体性能明显高于未启用时，且运行稳定性更佳。

Oracle 数据库跨平台迁移验证

接下来，我们围绕 Oracle 数据库从 x86 平台迁移至海光平台进行了一系列验证。

使用跨集群迁移功能实现 Intel/Hygon 平台间互相迁移

首先，我们验证了现有 Oracle 虚拟机从 x86 平台迁移至海光平台的可行性。对于已经在 x86 平台运行的 Oracle 虚拟机，我们提供了跨集群迁移功能，可以将其直接从 Intel x86 的 SmartX 集群迁移至海光平台。测试结果表明，无论迁移方向如何，通过跨集群冷迁移均能成功完成，且无需对数据库做任何改动，迁移后的数据库可直接启动并正常运行。

通过 ADG 集群实现 Intel/Hygon 数据库主备复制

具体验证方案是将主库部署在 Intel 平台，备库部署在海光平台，主备之间通过 ADG 实现复制与故障切换。

测试一：主库使用Red Hat Enterprise Linux 7.9，备库使用 KylinOS v10。在该组合下，数据同步与一致性均无问题，但在主备切换、网络故障等场景中出现失败。
测试二：主库与备库均使用 Red Hat Enterprise Linux 7.9。在此环境下，ADG 不仅能正常完成主备同步，还能顺利执行手动切换、故障切换与恢复任务。

从测试结论看，在海光平台上部署 ADG 时，主备节点建议使用相同版本的 Linux 7.9 操作系统。

进一步的网络带宽测试表明，在 25G 网络与 1G 网络下，ADG 复制带宽占用均约为 200+ Mbps，性能差距不大，说明 1G 网络即可满足大多数场景的需求。

Intel -> Hygon 迁移前后 Oracle 性能对比

最后，我们再提供一组将 Oracle 数据库从 Intel 平台迁移到海光平台前后的性能对比，供读者参考。

测试环境中，Intel 集群与海光集群的硬件配置并不是完全对等，但总体接近：首先，两者的 CPU 主频接近（Intel Xeon 5218R 主频为 2.1GHz，而海光 7285 主频为 2.0GHz）；此外，SSD 缓存盘型号虽有差异，但两者性能上也是比较接近的，Intel 集群上的 SSD 随机读写性能上略优。

测试利用 Cloudtower 跨集群迁移功能将 Oracle 虚拟机从 Intel 平台整机迁移至海光平台，配置保持不变的情况下对数据库进行压力测试。结果显示，Oracle 迁移至海光平台后，在多个并发场景下仍旧能维持原有性能的 60%-70%，且整体运行平稳，可满足一般业务运行要求。

更多数据库场景性能评测与探索实践，欢迎下载《SmartX 产品在数据库场景下的测试与实践合集》电子书！