存款核心、贷款核心和会计核心作为银行的核心系统，其稳定性和性能直接影响到银行几乎所有其他业务系统的平稳运行。而面对银行业务（尤其是网贷业务）的快速发展与业务数据量的激增，某头部区域银行急需对支撑核心业务系统的 Oracle 数据库备库进行“降本增效”，因此对 SmartX 榫卯超融合支撑 Oracle ADG 备库的能力进行了测试验证。结果表明，榫卯超融合环境下 ADG 延迟和稳定性远优于 vSAN 架构，与中高端全闪集中式存储表现相当。
下载《SmartX 产品在数据库场景下的测试与实践合集》，了解更多 Oracle 数据库场景下的性能验证与实践！
测试背景
对于存款、贷款等核心业务系统，该区域银行采用 Oracle 数据库（主库+ADG 备库）进行支撑，其中主库采用“物理机+国产高端全闪集中式存储”的架构，备库采用 vSphere+vSAN 支持运行。随着网贷业务的快速发展，业务数据量急速增长，为了缓解核心数据库压力，部分查询业务由备库完成，报表和报送等数据处理业务由备库转发至大数据平台完成。不过，使用过程中用户发现备库的性能逐渐难以满足日趋增长的业务需求：
- 跑批场景下备库资源池的 I/O 能力无法满足实时复制要求，在日结批时出现超过 30 分钟的 apply delay。
- 日结批后立刻开始的大数据 ETL 抽取的数据有 30 分钟偏差，导致了报表、监管报送数据甚至前端查询业务数据的不准确情况。
同时，考虑到博通收购 VMware 后带来较大的订阅成本上涨，，该银行计划寻求备库 vSAN 资源池的替代方案。初期，用户尝试将备库切换至既有的国产全闪集中式存储上，虽然该方案能够解决备库资源池 I/O 能力不足的问题，但由于集中式存储同时承载核心交易业务的主库及其他高 I/O 需求的备库，容量需求巨大，导致扩容成本高昂，且存在潜在的性能干扰风险，用户想要寻求更为经济、稳定的替代方案。
为了平衡性能、成本和可靠性，用户决定验证国产超融合架构承载备库的可行性。由于用户此前已在生产环境基于 SmartX 榫卯超融合（采用原生虚拟化 ELF）承载了除核心账务系统 Oracle 数据库之外全部 100+ 生产业务系统的 MySQL 数据库从库，用户计划对榫卯超融合的 Oracle 备库承载能力进行测试验证。
测试方案
测试在生产环境中进行，采用对比分析的方法，同时运行三个集群的备库：vSAN 集群、全闪集中式存储和榫卯超融合集群。所有集群配置保持一致，重点监控 ADG 延迟指标，以确保数据实时复制的可靠性。测试旨在模拟真实业务场景，特别是在日结批处理的高峰期，通过监控脚本实时捕获备库的延迟数据。
测试结果
通过为期近一个月的监控，可以看到，vSAN 集群大部分时间延迟可以满足要求，但由于性能不稳定，在一个月内出现了多次延迟急剧增加的情况，最大达到了 900 多秒；而全闪集中式存储和榫卯超融合集群的性能则非常稳定，高峰期延迟稳定在 100 秒以下，最大延迟分别是 78 秒和 85 秒，表现远优于 vSAN 集群。
这一测试结果表明，榫卯超融合在处理高 I/O 负载时，尤其在数据实时复制场景下，能够满足核心业务的时效要求。未来，该银行计划根据不同场景，使用榫卯超融合与榫卯分布式存储（存算分离架构），逐步扩展并支撑现有 Oracle 数据库主库和备库。
实践收益
- 基于 SmartX 榫卯超融合平台的 Oracle ADG 备库延迟测试，验证了超融合架构承载银行核心数据库备库的能力。
- 验证了分布式存储对中高端集中式存储的替代能力，为银行用户在全云数据中心时代的数字化转型提供了新的建设思路。
- 超融合承载核心数据库可以大大降低传统方案下银行对于中高端存储设备的依赖，同步降低硬件采购成本和运维成本。
更多 SmartX 产品在 Oracle 数据库场景下的性能验证，欢迎下载电子书《SmartX 产品在数据库场景下的测试与实践合集》。
推荐阅读：
银行用户 SAS 风控跑批测试：分布式分层全闪跑赢集中式全闪
超融合架构加速银行核心系统跑批效率
)
)