我们家 OEM 工厂 1000+ Oracle 存储过程要重构，迁移路径分享
CosDev 自己有个长期客户嘉氏堂，2017 年帮他们做的 OEM ERP，因为客户 IT 团队熟 Oracle，整套业务逻辑放在 1000+ 存储过程里。8 年下来运行稳定但维护越来越重。
痛点
- Oracle 19c license 每年 ¥40 万
- 存储过程的版本管理弱
- 新员工不懂 Oracle PL/SQL
- 性能瓶颈在并发场景显现
重构原则（INCILABSV2 项目正在做这事）
- 不一次性切换——逐模块重构，PG 和 Oracle 并存运行 6-12 个月
- 业务逻辑从存储过程上提到 Python（FastAPI）——更容易测、好版本管理、易招人
- 数据迁移最后做——前期都是 dual-write 验证一致性
- 每模块切换前必须有 100% 业务回归测试（自动化）
时间盘子
按模块拆，BSE → SAL → PUR → INV → LAB → QC → SFC → SAM → RPT。 每个模块 2-4 个月。整体 18-24 个月。
预算估算
按 1000 存储过程估算：3-5 个工程师 × 18-24 个月 ≈ ¥350-600 万。
关键决策：保留 80% 业务逻辑不动，只改"承载形式"（存储过程 → Python service）。这样客户业务团队几乎无感。
有同样在做这事的兄弟欢迎私信交流细节。
3 条回复
按热度 ▾同样是 Oracle 1500+ 存储过程的客户 IT。这条路我们也在评估，预算估算和你给的 ¥350-600 万非常一致。dual-write 验证一致性这步具体怎么做？
对存储过程的核心逻辑还是 Oracle 比 PG 强一点（嵌套游标 / 层次查询 / 分析函数）。如果迁过去，部分高频查询要重写优化，会不会反而性能下降？
@林 IT @高研发副总 两个问题都关键：
dual-write 验证
核心思路：业务方调"新接口"（Python service），新接口内部 ① 调老存储过程 ② 调 PG 业务逻辑 ③ 比对结果差异 → 写入差异表。运行 1-3 个月差异率 < 0.01% 后切换。比对维度包括：返回值 / 影响行数 / 副作用（写入哪些表）。
Oracle vs PG 性能
实测下来：80% 查询 PG 持平或更快（PG 12+ 之后查询规划器追上来了）；20% 性能敏感的（深层嵌套游标、复杂分析函数）需要专门优化或改写为 Python service + 多次查询。最坏 case 不会比 Oracle 慢 30%。
CosDev 在 INCILABSV2 项目验证了这条路径，数据已上 PG 4 万+ 配方 + 38 万+ 物料 + 1.5 M NMPA 备案，单查询 < 200ms。