本文的主角是国内成立时间最早的基金管理公司之一，管理总规模超过万亿元人民币，旗下公募产品数百只，以ETF见长，规模持续位居行业前列，是市场上具有相当代表性的老牌机构。了解这家公司的IT现状，需要先理解公募基金行业的技术生态。
相比制造、零售等行业，公募基金的业务系统高度碎片化——交易、估值、清算、风控、报告，每个链条的核心系统往往由不同的软件厂商提供，选型决策分散在不同部门和不同历史时期。结果是，数据库品牌的“多元化”几乎是这个行业的共同特征。
这家公司的数据库清单，到去年年中大致是这样的：Oracle（12c、19c、RAC均有）、MySQL、达梦DM（2023年信创改造后陆续上了4套）、OceanBase（1套生产环境）、GaussDB openGauss（试点中）。
一位熟悉该公司信创改造项目的技术人士用了一个很形象的说法：“住户各有各的规矩，彼此互不干涉。”实际上，问题不在于“住户多”，而在于“物业”是分散的。
Oracle连着独立的FC-SAN存储；MySQL跑在KVM虚拟机里；国产数据库上线时，按各自厂商的建议划了独立的存储空间。每套数据库的容量预留、快照策略、故障恢复逻辑，各成体系。DBA团队每日巡检，要切换多个平台，同一个告警可能从三个不同的通知系统同时推送——内容还不一样，需要先判断“哪条是真正需要关注的”，再去处理。
这种状态“凑合能过”，但从IT管理角度看，是一种长期积压的效率损耗和隐性风险。
2023年至今，公募基金行业的信创进度明显提速。监管口径、信创政策、国产数据库厂商的生态成熟度，多重因素叠加，让“Oracle替换”成为各家IT负责人的高频议题。
但在真正实践过的公司里，一个判断逐渐形成共识：Oracle在短期内不会消失，国产数据库也不会独占，两者共存是至少5年内的行业常态。
这个判断背后的逻辑并不复杂。核心交易系统迁移Oracle的技术风险和业务风险都相当高；而监管层面的信创要求又让新建系统必须优先采用国产数据库。两条线并行推进，“混跑”成了必然结果。
这一判断，把问题从“换哪个数据库”，重新定向到了“怎么管好一堆数据库”。
在启动这次基础架构重建前，该基金管理公司的IT团队明确了三个核心诉求：
-
第一，存储资源必须统一管理。不同数据库各自占一块独立存储的“烟囱模式”必须打破——Oracle用的那块，OceanBase用不了；OceanBase申请多了用不完，Oracle这边偶尔又捉襟见肘。容量利用率长期在50%左右徘徊，是可以改变的。
-
第二，运维视角必须统一。DBA不管面对国外传统商业数据库，还是开源数据库，亦或是国产信创数据库，部署、巡检、监控告警、性能容量分析、高可用管理等运维操作都要在同一个平台完成。
-
第三，扩展必须在线。业务增长节奏快，存储容量扩展不能再依赖停机割接，否则每次扩容都是一次风险事件。
经过约三个月的调研和PoC测试，该基金管理公司最终选择了云和恩墨的zData X多元数据库一体化承载平台。
从技术架构看，zData X是一套将计算、存储、网络、运维软件整合在一起的数据库基础设施运行平台，以一体机的形态交付，其核心主张是：底层统一承载多种数据库，上层提供统一的运维管理能力。
支撑这一主张的，是两个关键的技术模块。
-
zStorage：把烟囱变成水池
zStorage是平台内置的、专门针对数据库应用而研发的高性能分布式块存储系统。它的做法是把所有存储节点的NVMe磁盘汇聚成一个统一的存储资源池，再根据需要为各个数据库实例动态分配块存储卷。
在本文提到的基金管理公司的实践中，部署的存储侧配置为3台服务器，每台搭载14块3.84TB NVMe PCIe 4.0固态盘，内部网络走100Gb/s RoCE高速以太网，总可用存储量在百TB量级，扩展上限达1024节点。
这套设计的直接效果，是把原本各自孤立的存储空间变成了一个可动态调配的公共资源池。各系统不再需要为“万一容量不够”而提前多预留，高峰期可以动态借用低峰期系统的空间余量。
-
zManager：一个界面管所有
对于该基金管理公司的DBA团队来说，感受最直接的变化来自运维平台的统一。
zManager统一接管了运行在平台上的Oracle、MySQL、达梦DM、OceanBase等所有数据库实例——实时监控、告警收口、自动巡检、性能容量趋势分析，全部集中在统一界面。
技术团队提供了项目验收测试时的两组对比数据：
- 日常巡检耗时：从每次约2小时，缩减至约5分钟，即通过自动化巡检报告，DBA每天只需要花5分钟看看系统有没有问题就可以了；
- 告警频次：从平均3.2次/周，降至约1.1次/周。
告警质量的提升被认为同等重要。以前告警来自多套系统，误报和重复报干扰明显；统一告警通道后，DBA不再需要在多个通知群里先做“真假判断”，才能着手处理。
事实上，对于存储池化方案，该基金管理公司的项目决策团队起初并不是没有疑虑——多个数据库系统共用一套存储基础设施后，是否会相互干扰、争抢带宽？
为此，云和恩墨的技术团队在PoC阶段重点测试这个场景。平台的内部存储网络采用RoCE（基于以太网的RDMA远程直接内存访问）协议——计算节点可以绕过操作系统内核，直接访问存储节点内存，延迟极低，CPU额外开销极小。
实测结果是：Oracle RAC和达梦DM同时承载业务负载时，彼此的I/O延迟相较独占存储时无明显上升。平台还提供QoS管理功能，支持对不同数据库实例分别设置IOPS和MBPS上限，确保核心交易系统优先获得存储资源。
出于金融监管要求和业务连续性的严苛需求，该基金管理公司在验收阶段重点测试了两个场景。
-
故障自愈：平台采用多副本存储机制（本案例实践选择了性能三副本模式，两副本写成功即返回，第三副本异步写，相比传统三副本写入延迟降低约50%）。模拟单块NVMe盘故障时，平台自动触发数据重构，实测重构速度约7TB/h，上层数据库业务全程无感知。
-
静默错误检测：这是容易被忽视但在金融行业实际存在风险的场景——数据在存储传输过程中，因硬件老化或固件问题发生bit级错误，而上层应用和操作系统均无法察觉。平台在I/O路径上设置校验机制，写入时插入校验位，读取时验证，发现不一致则自动从正确副本恢复。
这次基础架构重建项目于2025年末开始部署，2026年1月初正式上线，截至本文撰稿时已稳定运行3个月。主要运行数据如下：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这组数据传递的核心信号是：多种数据库在同一套基础设施下共存，不仅技术上可行，实际运行中也未引入额外的不稳定性。存储利用率的提升和运维效率的改善，是目前最为直接可量化的收益。
当然，任何一次深度的底层IT架构升级，都需要经历严谨的磨合与过渡。从zData X部署上线后的实际运行情况来看，本次改造沉淀了三个值得行业借鉴的实战经验：
-
国产数据库运维生态的加速演进：zManager在Oracle的深度运维（如ASM恢复、RAC管理、AWR报告对接等）方面已非常成熟且完整。而随着国产化进程加速，面向达梦、OceanBase等国产数据库的运维精细度（如慢SQL历史回溯、执行计划分析等）正成为全行业的共同课题。目前，云和恩墨正将Oracle领域的成熟经验加速向国产数据库迁移，在后续的敏捷迭代中，将持续引领国产数据库深度运维能力的构建。
-
运维习惯的高效无缝切换：引入新一代架构必然伴随运维逻辑的升级。得益于zData X相对友好的交互设计，以及云和恩墨团队提供的驻场服务与体系化培训，该基金管理公司DBA团队仅用约2周时间，便高效跨越了工具切换期，熟练掌握了全新的日常操作流程，实现了运维能力的平滑过渡。
-
稳妥可靠的分步建设策略：针对核心系统的改造，项目组采取了“稳字当头、分步实施”的策略。目前，生产侧的平稳运行及灾备侧的存储扩容已圆满完成；为确保业务绝对安全，生产与灾备的一体化全局管理被列入下一阶段的建设蓝图，这将是双方团队后续深化合作的核心看点。
这家基金管理公司的案例，折射的是整个金融行业在信创推进过程中面临的共性困局。
围绕“该不该换Oracle”“换成哪家国产数据库”的讨论已经持续多年，但在实际操作层面，决策者面对的往往不是非此即彼的选择，而是如何让多种数据库体系在同一套基础设施上都跑得稳、管得好。从这个角度看，“多元数据库一体化承载”可能比“数据库国产化替换”更接近当前多数金融机构的真实命题。
数据库本身的争论或许还会持续很久，但底层的存储和运维平台正在悄然重构数据库基础设施的运行模式。当一栋“数据库混居楼”的地基已经筑牢、主体结构已经封顶，硬装已经完善，哪个住户不都可以“拎包入住”了嘛。