📌 核心论点 基金估值核算系统是公募基金的"生产心脏"——每日收盘后对数千只基金产品进行份额净值计算、资产估值、收益分配，是监管报送和投资者申赎的基石。这个系统长期深度依赖 Oracle 数据库（复杂存储过程、PL/SQL 包、DBLink 跨库查询），信创迁移被称为"在高速飞行的飞机上换发动机"。
2026 年，平安基金联合赢时胜实现估值核算系统 V5.5 信创版全栈国产化（OceanBase+麒麟+自研 Rockyas 中间件），96% 以上产品可在 19:00 前完成日终估值，跑批性能与 Oracle 环境下的信创版本基本持平；嘉实基金 TA 系统以金仓数据库替换 Oracle，70TB 数据、230+ 复杂存储过程、RTO≤15 秒金融级容灾，成为中国首批千亿级公募核心登记系统国产化落地标杆。
这两个案例，为行业梳理出一条"评估→双轨→迁移→调优→单轨“的五阶段实战路径。理解这条路径的每个环节、每个坑、每个性能攻坚手段，是基金公司在 2027 年信创大限前做对迁移决策的关键。
一、为什么估值核算系统的 Oracle 迁移是"最难啃的骨头”#
1.1 估值核算系统的核心地位#
公募基金每日运营的核心生产链路是：
日终收盘 → 接收行情/持仓/交易数据 → 估值核算（核心）
→ 计算份额净值/资产净值 → 监管报送 → 信息披露 → 投资者申赎估值核算系统是这条链路的"计算心脏"，其产出（基金份额净值、资产净值）直接关系到：
- 监管合规：净值计算错误将导致监管处罚
- 投资者利益：净值是申赎定价的基础
- 信息披露：每日净值公告、季报年报的数据来源
1.2 Oracle 深度依赖的四大"技术债"#
基金行业核心系统长期运行在 Oracle 之上，形成了四层深厚的技术债：
① 复杂存储过程（230+ 个）
以嘉实基金 TA 系统为例，迁移前存在 230+ 个 Oracle 复杂存储过程，这些过程封装了：
- 份额登记与过户逻辑
- 分红再投资计算
- 巨额赎回判断与处理
- 管理费/托管费计提
- 业绩报酬计算
这些存储过程大量使用 Oracle 特有的 PL/SQL 语法、内置包（DBMS_、UTL_）、动态 SQL，直接迁移到国产数据库需要逐条改写或适配。
② PL/SQL 包与对象类型
Oracle 的对象类型（OBJECT TYPE）、集合类型（TABLE TYPE、VARRAY）、管道函数（PIPELINED FUNCTION）在估值核算中被广泛用于：
- 批量数据处理
- 复杂计算的中间结果传递
- 报表生成
这些特性在国产数据库中的支持程度差异很大，是迁移兼容性的核心挑战。
③ DBLink 跨库查询
估值核算系统通常需要与 TA 注册登记系统、投资交易系统、资金清算系统交互，通过 Oracle DBLink 实现跨库查询和数据同步。国产数据库需要替代这一能力（如 OceanBase 的 DBLink、KingbaseES 的跨库查询）。
④ 高并发跑批与性能要求
日终跑批是估值核算系统最重的负载：
- 数千只基金产品并发计算
- 单产品可能涉及数百万条持仓记录
- 跑批窗口有限（通常要求在 19:00 前完成，以便晚间监管报送）
- 性能下降直接导致运营人员加班、监管报送延迟
💡 核心挑战：估值核算系统的 Oracle 迁移，不是简单的"数据库替换"，而是业务逻辑重新适配 + 性能重新调优 + 业务连续性全程保障的系统性工程。这也是为什么平安基金案例（96% 产品 19:00 前完成估值）和嘉实基金案例（70TB 数据迁移）被视为行业标杆——它们证明了这条路走得通、走得稳。
二、两条已验证的迁移路径#
2.1 路径 A：OceanBase 路线（平安基金+赢时胜）#
适用场景：估值核算系统、统一支付平台、运营风险管控等核心生产系统全栈信创。
技术栈：
数据库：OceanBase（原生分布式，Oracle 兼容模式）
操作系统：麒麟
中间件：平安自研 Rockyas 中间件
安全：高可用、高安全的全栈信创架构核心成果（平安基金 V5.5 信创版）：
- 公募行业首例估值相关系统全栈国产化落地标杆
- 涵盖估值核算 5.5、统一支付平台 5.5、运营风险管控 2.0、自动化估值、日常报表、信息披露、PCF 篮子等全系列信创解决方案
- 截至 2026 年 3 月，平稳运行半年，顺利通过年终结算检验
- 96% 以上产品可在 19:00 前完成日终估值
- 整体跑批性能与 Oracle 环境下的信创版本基本持平
- 达成"性能不下降"核心目标
2.2 路径 B：金仓 KingbaseES 路线（嘉实基金 TA 系统）#
适用场景：TA 注册登记系统、核心登记系统等 Oracle 迁移替换。
技术栈：
数据库：金仓 KingbaseES V8（Oracle 兼容模式）
迁移工具：KDTS 全量迁移工具 + KFS 实时增量同步平台
操作系统：国产操作系统（信创环境）核心成果（嘉实基金 TA 系统）：
- 总数据量近 70TB
- 日均清算峰值并发 16 路
- 230+ Oracle 复杂存储过程迁移替换
- RTO≤15 秒金融级容灾要求
- 成功实现"业务平稳过渡、数据完整可靠、性能显著提升"三大核心成果
- 成为中国首批千亿级公募基金公司核心登记系统国产化落地的重要实践参考
2.3 两条路径的对比#
| 维度 | OceanBase 路线（平安） | 金仓 KingbaseES 路线（嘉实） |
|---|---|---|
| 数据库定位 | 原生分布式 OceanBase（Oracle 兼容模式） | 集中式+分布式 KingbaseES V8（Oracle 兼容） |
| 适用系统 | 估值核算、支付、风控、报表、信息披露 | TA 注册登记、核心登记系统 |
| 数据规模 | 数千只基金产品日终跑批 | 70TB 总数据量 |
| 复杂对象 | 估值核算业务逻辑（存储过程、函数） | 230+ Oracle 复杂存储过程 |
| 性能目标 | 96% 产品 19:00 前完成估值（与 Oracle 持平） | 性能显著提升，RTO≤15 秒 |
| 迁移工具 | 赢时胜自研一键式数据迁移工具 | KDTS 全量迁移 + KFS 实时增量同步 |
| 平滑过渡 | 双轨并行 + 按产品/分表迁移 + 断点续传/回迁 | KDTS+KFS 全量+增量同步 |
| 行业意义 | 公募首例估值系统全栈国产化 | 千亿级公募核心登记系统国产化标杆 |
💡 选型启示：估值核算系统（计算密集、跑批窗口敏感）优先选 OceanBase 分布式路线（分布式架构天然适配高并发跑批）；TA 注册登记系统（事务密集、存储过程多）可选金仓 KingbaseES（Oracle 兼容能力强，230+ 存储过程迁移经验成熟）。
三、五阶段实战路径：从评估到单轨#
综合平安基金、嘉实基金等标杆案例，基金估值核算系统 Oracle→OceanBase 迁移可归纳为五阶段实战路径：
阶段一：评估与兼容性分析（4-8 周）#
目标：摸清"家底"，评估迁移可行性与工作量。
核心动作：
① 对象清单梳理
- 表结构（表数量、分区表、索引、约束）
- 存储过程/函数/触发器（数量、复杂度、Oracle 特有语法使用比例）
- 序列、同义词、DBLink、物化视图
- 定时任务（DBMS_JOB/DBMS_SCHEDULER）
② 兼容性评估
OceanBase Oracle 兼容模式支持情况评估：
| Oracle 特性 | OceanBase 兼容度 | 迁移策略 |
|---|---|---|
| 基本数据类型 | ✅ 高度兼容 | 直接迁移 |
| DML/DDL | ✅ 高度兼容 | 直接迁移 |
| PL/SQL 存储过程/函数 | ✅ 大部分兼容 | 少量语法适配 |
| 包（PACKAGE） | ✅ 支持 | 直接迁移 |
| 对象类型/集合类型 | ⚠️ 部分支持 | 改写或替代 |
| 管道函数 | ⚠️ 部分支持 | 改写为常规函数 |
| DBLink | ✅ 支持 | 直接迁移或改写 |
| 动态 SQL（EXECUTE IMMEDIATE） | ✅ 支持 | 直接迁移 |
| 内置包（DBMS_、UTL_） | ⚠️ 部分支持 | 寻找替代方案 |
| 并行查询 | ✅ 支持 | 直接迁移 |
③ 性能基线建立
- 在 Oracle 环境采集日终跑批的基线性能数据（各产品估值耗时、总跑批耗时、峰值并发）
- 作为迁移后性能对比的基准
④ 风险评估报告
- 识别高风险的 Oracle 特有依赖（如深度使用 UTL_FILE、DBMS_PIPE 等）
- 评估改写工作量
- 制定兼容性适配方案
平安基金经验：赢时胜联合数据库厂商开展专项技术攻关，通过索引重构、SQL 拆分、代码改造、细化并发参数调优等手段，提前识别性能瓶颈点。
阶段二：双轨并行环境搭建（4-8 周）#
目标：搭建 OceanBase 生产环境，与 Oracle 旧系统并行运行。
核心动作：
① OceanBase 集群部署
- 生产环境：建议 3 副本（或 5 副本）OceanBase 集群，跨机房/跨机架部署
- 资源配置：根据基金产品数量和数据量确定 OBServer 节点数和规格
- 高可用：RPO=0，RTO<30 秒（金融级容灾）
② 数据初始迁移
- 使用 OceanBase 迁移工具（或第三方工具）完成全量数据迁移
- 校验数据一致性（行数核对、校验和比对、抽样数据比对）
③ 应用适配与改写
- 存储过程/函数/包：按兼容性评估结果逐条改写
- 应用 SQL：适配 OceanBase 语法差异
- 连接池/中间件：配置 OceanBase 数据源
④ 双轨并行架构
┌──→ Oracle（旧系统，只读/主写）
│
应用层 ──→ 流量分发层
│
└──→ OceanBase（新系统，并行运行）- 应用层通过流量分发层，将部分产品/部分业务的请求路由到 OceanBase
- 两套系统并行运行，数据定期比对校验
平安基金经验：采用双轨并行策略，避免"一刀切"切换的业务中断风险。推出自研一键式数据迁移工具，支持按产品、分表迁移数据，具备断点续传与回迁功能。系统在界面设计、操作流程与数据接口等方面全面延续用户原有使用习惯。
阶段三：数据迁移与一致性校验（2-4 周）#
目标：完成全量数据迁移，确保新旧系统数据完全一致。
核心动作：
① 全量迁移
- 使用迁移工具完成全量数据迁移
- 嘉实基金案例：70TB 数据通过 KDTS 全量迁移工具完成
② 增量同步
- 迁移期间 Oracle 仍在运行，增量数据通过实时同步工具捕获
- 嘉实基金案例：KFS 实时增量同步平台捕获 Oracle 增量 REDO，实时同步到 KingbaseES
③ 数据一致性校验
- 行数核对：每张表新旧系统行数一致
- 校验和比对：关键表计算校验和（CHECKSUM）比对
- 抽样数据比对：抽取关键业务数据逐字段比对
- 业务指标校验：基金净值、份额、资产净值等关键指标比对
④ 回迁演练
- 验证从 OceanBase 回迁到 Oracle 的能力（应急保障）
- 平安基金迁移工具具备"回迁功能"，确保切换可逆
阶段四：性能攻坚与调优（4-8 周）#
目标：使 OceanBase 环境的跑批性能达到或接近 Oracle 基线水平。
这是整个迁移过程中技术含量最高、最具决定性的阶段。
核心调优手段（平安基金实战经验）：
① 索引重构
- 分析跑批 SQL 的执行计划，识别全表扫描
- 为高频查询条件、连接条件、排序字段建立合适索引
- 删除冗余索引（减少写入开销）
② SQL 拆分
- 将大事务拆分为小事务，减少锁竞争
- 将复杂嵌套 SQL 拆分为多步执行
- 批量操作改为分批提交
③ 代码改造
- 改写不兼容的 PL/SQL 代码
- 将管道函数改写为常规函数
- 优化循环逻辑，减少上下文切换
④ 并发参数调优
- OceanBase 并行度参数（parallel_degree_policy、parallel_degree）
- 连接池大小调优
- 内存参数调优（MemStore 大小、转储阈值）
⑤ 分区策略优化
- 大表按产品/日期分区，减少单分区数据量
- 分区裁剪提升查询性能
性能验收标准（参考平安基金标杆）：
| 指标 | Oracle 基线 | OceanBase 目标 |
|---|---|---|
| 日终跑批总耗时 | T_oracle | ≤ T_oracle（持平或更快） |
| 19:00 前完成估值产品比例 | 基准比例 | ≥96% |
| 单产品估值平均耗时 | t_avg | ≤ t_avg |
| 峰值并发 | 16 路（嘉实案例） | 不低于 Oracle |
平安基金成果：通过索引重构、SQL 拆分、代码改造、细化并发参数调优，96% 以上产品可在 19:00 前完成日终估值，整体跑批性能与 Oracle 环境下的信创版本基本持平。
阶段五：单轨上线与旧系统下线（2-4 周）#
目标：将生产流量全部切到 OceanBase，Oracle 旧系统进入只读/下线流程。
核心动作：
① 灰度切换
- 第一批：低风险产品（如货币基金、债券基金）切换到 OceanBase
- 第二批：中等风险产品（如混合基金）切换
- 第三批：高风险产品（如 QDII、分级基金）切换
- 每批切换后观察 1-2 个跑批周期，确认稳定后再推进
② 全量切换
- 所有产品跑批在 OceanBase 环境完成
- Oracle 旧系统进入只读模式（保留 1-3 个月作为应急回退）
③ 旧系统下线
- 数据归档（按监管留存要求）
- Oracle 环境下线
- 完成信创验收
平安基金经验：系统平稳运行半年，顺利通过年终结算检验，验证了单轨运行的稳定性。
四、关键风险清单与应对策略#
4.1 兼容性风险#
| 风险点 | 影响 | 应对策略 |
|---|---|---|
| Oracle 特有语法不兼容 | 存储过程迁移失败 | 提前兼容性评估，逐条改写 |
| 内置包（DBMS_/UTL_）不支持 | 功能缺失 | 寻找替代方案或用 Java/PLSQL 重写 |
| 对象类型/集合类型差异 | 复杂数据结构迁移困难 | 改写为关系表或常规集合 |
| DBLink 跨库查询 | 跨系统交互中断 | 使用 OceanBase DBLink 或应用层整合 |
4.2 性能风险#
| 风险点 | 影响 | 应对策略 |
|---|---|---|
| 跑批性能下降 | 19:00 前无法完成估值 | 索引重构+SQL 拆分+并发调优 |
| 高并发下响应变慢 | 运营人员体验下降 | OceanBase 并行查询+分区优化 |
| 大事务锁竞争 | 跑批超时 | 大事务拆分为小事务 |
| 统计信息不准确 | 执行计划劣化 | 定期收集统计信息 |
4.3 数据一致性风险#
| 风险点 | 影响 | 应对策略 |
|---|---|---|
| 迁移过程数据丢失 | 业务数据不完整 | 全量+增量双校验 |
| 双轨期间数据漂移 | 新旧系统结果不一致 | 定期数据比对+差异修复 |
| 回迁失败 | 切换不可逆，应急能力丧失 | 迁移工具必须具备回迁功能 |
4.4 业务连续性风险#
| 风险点 | 影响 | 应对策略 |
|---|---|---|
| 切换期间系统不可用 | 运营中断 | 双轨并行，灰度切换 |
| 切换后功能异常 | 业务错误 | 充分测试+应急回退预案 |
| 年终结算期间故障 | 监管风险 | 避开年终结算窗口切换 |
五、OceanBase vs 金仓：选型决策指南#
5.1 什么时候选 OceanBase？#
✅ 优先选 OceanBase 的场景：
- 估值核算系统：高并发跑批、数千产品并行计算，OceanBase 分布式架构天然适配
- 数据量持续增长：OceanBase 分布式扩展能力强，支持 PB 级数据
- 需要 Oracle 兼容+分布式：既要 Oracle 语法兼容，又要分布式水平扩展
- 金融级高可用要求：OceanBase 原生 Paxos 多副本，RPO=0，RTO<30 秒
- 云化部署：OceanBase Cloud 支持多云部署
代表案例：平安基金估值核算 V5.5 信创版（OceanBase+麒麟+Rockyas）
5.2 什么时候选金仓 KingbaseES？#
✅ 优先选金仓 KingbaseES 的场景：
- TA 注册登记系统：事务密集、存储过程多（如嘉实 230+ 存储过程），金仓 Oracle 兼容能力强
- 集中式架构偏好：不需要分布式扩展，集中式部署更简单
- 存量 Oracle 应用迁移：金仓在 Oracle 语法/数据类型/存储过程兼容方面积累深厚
- 国产数据库自主可控要求高：金仓是人大金仓（CETC 系）产品，国产化属性强
代表案例：嘉实基金 TA 系统（70TB 数据、230+ 存储过程、RTO≤15 秒）
5.3 选型决策矩阵#
| 评估维度 | OceanBase 得分 | 金仓 KingbaseES 得分 |
|---|---|---|
| Oracle 兼容度 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 分布式扩展 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| 高并发跑批 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| 存储过程迁移 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 金融级高可用 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| 云化部署 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| 国产化属性 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 社区生态 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
💡 决策建议：估值核算系统（计算密集、跑批窗口敏感）选 OceanBase；TA 注册登记系统（事务密集、存储过程多）选金仓 KingbaseES。大型基金公司可"双库并行"——不同业务系统选用最适合的数据库。
六、迁移工具链推荐#
6.1 OceanBase 迁移工具链#
| 工具 | 用途 | 说明 |
|---|---|---|
| OceanBase Migration Service（OMS） | 数据迁移+增量同步 | 支持 Oracle→OceanBase 全量+增量迁移 |
| OceanBase Developer Center（ODC） | SQL 开发+调试 | PL/SQL 开发调试环境 |
| 自研迁移工具（赢时胜模式） | 按产品/分表迁移+断点续传+回迁 | 基金公司/厂商自研，贴合业务 |
6.2 金仓 KingbaseES 迁移工具链#
| 工具 | 用途 | 说明 |
|---|---|---|
| KDTS | 全量数据迁移 | 支持 Oracle→KingbaseES 全量迁移 |
| KFS | 实时增量同步 | 捕获 Oracle REDO，实时同步到 KingbaseES |
| KDMS | 迁移评估 | Oracle 对象兼容性评估 |
6.3 通用工具#
| 工具 | 用途 |
|---|---|
| 数据比对工具 | 新旧系统数据一致性校验（行数/校验和/抽样） |
| SQL 执行计划分析工具 | 性能调优、索引优化 |
| 监控告警平台 | 迁移期间实时监控数据库性能 |
七、行业标杆案例深度复盘#
7.1 平安基金：估值核算全栈信创的"性能不降级"标杆#
项目背景：
- 公募行业首例估值相关系统全栈国产化
- 涵盖估值核算 5.5、统一支付平台 5.5、运营风险管控 2.0 等全系列信创解决方案
- 合作方：平安基金 + 赢时胜 + OceanBase + 麒麟 + 平安自研 Rockyas
迁移路径：双轨并行 → 一键式数据迁移（按产品/分表+断点续传+回迁）→ 性能攻坚（索引重构+SQL 拆分+代码改造+并发调优）→ 全栈单轨
核心成果：
- 平稳运行半年，通过年终结算检验
- 96% 以上产品 19:00 前完成日终估值
- 跑批性能与 Oracle 信创版基本持平
- 达成"性能不下降"目标
可复制经验：
- 双轨并行避免"一刀切"风险
- 自研一键式迁移工具支持按产品/分表迁移+断点续传+回迁
- 索引重构+SQL 拆分+代码改造+并发调优四板斧是性能攻坚的有效手段
- 界面/操作流程/数据接口延续原有习惯，降低业务人员学习成本
7.2 嘉实基金：TA 系统 Oracle 迁移的"重量级"实践#
项目背景：
- 中国首批千亿级公募基金公司核心登记系统国产化落地
- 总数据量近 70TB
- 日均清算峰值并发 16 路
- 230+ Oracle 复杂存储过程
- RTO≤15 秒金融级容灾要求
迁移路径：KDTS 全量迁移 + KFS 实时增量同步 + 金仓 Oracle 兼容能力适配
核心成果：
- 业务平稳过渡、数据完整可靠、性能显著提升
- 70TB 数据完整迁移
- 230+ 存储过程成功迁移替换
- RTO≤15 秒金融级容灾达成
可复制经验：
- KDTS+KFS 全量+增量工具链成熟可靠
- 金仓 Oracle 兼容能力支撑 230+ 复杂存储过程迁移
- 千亿级数据规模下的金融级容灾（RTO≤15 秒）可行
八、2027 年信创大限前的时间窗口#
8.1 迁移周期估算#
| 阶段 | 周期 | 说明 |
|---|---|---|
| 评估与兼容性分析 | 4-8 周 | 摸清家底，评估可行性 |
| 双轨并行环境搭建 | 4-8 周 | 搭建 OB 环境+应用适配 |
| 数据迁移与一致性校验 | 2-4 周 | 全量迁移+增量同步+校验 |
| 性能攻坚与调优 | 4-8 周 | 索引/SQL/代码/并发调优 |
| 单轨上线与旧系统下线 | 2-4 周 | 灰度切换+全量切换+下线 |
| 合计 | 16-32 周（4-8 个月） | 一个完整迁移项目周期 |
8.2 时间窗口建议#
2026 年 Q3（现在）：启动评估与兼容性分析
↓
2026 年 Q4：完成双轨环境搭建+数据迁移
↓
2027 年 Q1：完成性能攻坚+灰度切换
↓
2027 年 Q2：全量单轨上线+旧系统下线
↓
2027 年 Q3-Q4：完成信创验收，预留缓冲⚠️ 关键提醒：2027 年是信创合规的关键节点。基金公司应在 2026 年下半年启动估值核算系统的 Oracle→OceanBase 迁移评估，最迟 2027 年上半年完成单轨上线，为信创验收预留缓冲时间。拖延至 2027 年下半年启动，将面临时间窗口不足的风险。
九、结语：基金估值核算信创迁移的"加速度"#
回到文章开头的核心问题——从 Oracle 到 OceanBase，基金估值核算系统信创迁移的实战路径是什么？
💡 这是一条已被平安基金、嘉实基金等标杆案例验证可行的"五阶段路径"：评估与兼容性分析 → 双轨并行环境搭建 → 数据迁移与一致性校验 → 性能攻坚与调优 → 单轨上线与旧系统下线。整个周期约 4-8 个月，核心是"双轨并行保连续、性能攻坚保体验、灰度切换保稳妥"。
三条核心启示：
- 估值核算系统选 OceanBase，TA 系统选金仓——根据系统特征匹配数据库，是迁移成功的前提
- 性能攻坚四板斧（索引重构+SQL 拆分+代码改造+并发调优）——平安基金 96% 产品 19:00 前完成估值的实战经验证明，信创迁移可以"性能不降级"
- 双轨并行+一键迁移+回迁保障——这是平滑过渡、风险可控的工程范式，避免"一刀切"切换的业务中断风险
一个共识：
📌 博主注：基金估值核算系统的 Oracle→OceanBase 迁移，是基金行业信创改造中技术难度最高、业务连续性要求最严、性能敏感性最强的核心战役。平安基金联合赢时胜实现估值核算全栈信创且 96% 以上产品 19:00 前完成日终估值，嘉实基金以金仓数据库替换 Oracle 完成 70TB 数据、230+ 存储过程的 TA 系统迁移——这两个标杆案例共同证明：基金核心系统的 Oracle 依赖，不是不可替代的技术壁垒，而是可以系统性攻克的工程挑战。
当 OceanBase 的 Oracle 兼容模式能够支撑数千只基金产品的日终跑批且性能与 Oracle 持平，当金仓 KingbaseES 能够承接 70TB 数据、230+ 复杂存储过程的核心登记系统且 RTO≤15 秒，中国公募基金核心系统的"计算心脏"，终于跳动的都是中国自己的数据库。2027 年信创合规节点前，这条"评估→双轨→迁移→调优→单轨"的五阶段路径，将成为基金公司最核心的迁移方法论——选对路径、用对工具、踩准节奏的基金公司，将在信创大潮中赢得先机。
附：Oracle→OceanBase 迁移实战路径速查表#
| 阶段 | 周期 | 核心动作 | 关键产出 | 风险提示 |
|---|---|---|---|---|
| 阶段一：评估 | 4-8 周 | 对象清单梳理、兼容性评估、性能基线建立、风险评估 | 兼容性评估报告、迁移可行性结论 | 兼容性评估不充分的，后期改写工作量会放大 |
| 阶段二：双轨搭建 | 4-8 周 | OB 集群部署、全量数据迁移、应用适配改写、双轨架构搭建 | OB 生产环境、应用适配版本 | 双轨期间数据一致性需持续校验 |
| 阶段三：迁移校验 | 2-4 周 | 全量迁移、增量同步、数据一致性校验、回迁演练 | 数据一致性校验报告、回迁能力验证 | 数据校验必须覆盖行数/校验和/抽样三个层次 |
| 阶段四：性能攻坚 | 4-8 周 | 索引重构、SQL 拆分、代码改造、并发调优、分区优化 | 性能达标（96% 产品 19:00 前估值） | 性能调优是最具决定性的阶段，需数据库厂商深度参与 |
| 阶段五：单轨上线 | 2-4 周 | 灰度切换（分三批）、全量切换、旧系统只读/下线 | 全栈信创单轨运行、信创验收 | 避开年终结算窗口切换 |
| 合计 | 16-32 周（4-8 个月） | — | — | — |
附：OceanBase vs 金仓 KingbaseES 选型速查表#
| 维度 | OceanBase | 金仓 KingbaseES |
|---|---|---|
| 架构 | 原生分布式（Shared-Nothing） | 集中式+分布式（V8） |
| Oracle 兼容 | Oracle 兼容模式 | Oracle 兼容模式 |
| 分布式扩展 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| 存储过程迁移 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐（230+ 案例） |
| 高并发跑批 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| 金融级高可用 | Paxos 多副本，RPO=0，RTO<30s | RTO≤15s（嘉实案例） |
| 云化部署 | OceanBase Cloud 多云支持 | 支持 |
| 代表案例 | 平安基金估值核算 V5.5 | 嘉实基金 TA 系统（70TB） |
| 最佳场景 | 估值核算系统（计算密集、跑批窗口敏感） | TA 注册登记系统（事务密集、存储过程多） |