一、为什么要迁？
说实话，最初的触发点很现实：续费通知。
Oracle 的 License 续费单发过来那一刻，财务和 IT 负责人同时沉默了几秒。不是第一次见到这个数字，但这一次，会议室里有人第一次认真说出那句话："我们真的还需要 Oracle 吗？"
这个问题背后，其实是三层积压已久的不满：
第一层：钱。Oracle 的 License 费用是个黑洞，每个处理器核心单独计费，RAC、分区、高级压缩……每个你以为理所当然的特性背后都藏着一张独立的账单。加上每年的技术支持费（通常是 License 费的 22%），每年花出去的钱，够搭两套新平台了。
第二层：锁定。数据在 Oracle 里，就是在 Oracle 的生态里。自研工具、开源组件、云原生架构——想用？先打个问号，先查兼容性，先问问 DBA 意见。每一次技术选型都要先看"Oracle 怎么说"，这种被动感越来越强。
第三层：时代变了。当 AI 应用开始需要直接读数据库、当实时数据管道成为标配、当分析师开始问"能不能直接查原始数据"——Oracle 那套以"稳定、封闭、一切我来管"为核心的设计哲学，和新时代的要求越来越格格不入。
所以我们启动了迁移项目。目标数据库：PostgreSQL + ClickHouse 组合（OLTP 走 PG，分析查询走 CK）。时间预期：三个月。
实际用了六个月。
二、迁移的账，要怎么算？
在讲过程之前，先把最核心的问题摆出来：迁移到底值不值，靠感觉是算不清的，要算账。
我们最终整理出了一张"真实成本对比表"，不是 PPT 里那种理想化的数字，是结合了所有隐性成本之后的版本：
Oracle 持有成本 vs 迁移后成本（年度估算）
| 对比维度 | Oracle（迁移前） | 迁移后（PG+CK） |
| 数据库软件费用 | License + 22% 年维护费 | 开源免费 / 云版本按量付费 |
| 硬件/云资源 | 为 Oracle RAC 专门配置高规格服务器 | 标准云实例，弹性扩缩 |
| DBA 人力成本 | 需要 Oracle 认证 DBA，市场薪资溢价 30%+ | 通用 DBA 可覆盖，招聘更容易 |
| 数据集成成本 | Oracle GoldenGate 等组件额外付费 | FineDataLink 统一接管，成本可控 |
| 开发效率 | 方言 SQL、专有特性，迁移三方工具成本高 | 标准 SQL，生态兼容性大幅提升 |
| 迁移一次性成本 | 无 | 人力 + 工具 + 停机风险补偿（一次性） |
算下来结论很清楚：迁移的一次性成本，通常在 1.5–2 年内可以通过年度费用节省回收。 如果你的 Oracle 合同还有 3 年以上，迁移的 ROI 是正的。
但"算清楚账"只是第一步，真正难的是接下来的执行。
三、六个月，我们踩了哪些坑？
坑 1：SQL 方言比想象中麻烦
Oracle 的 PL/SQL 和标准 SQL 的差距是真实存在的。我们有将近 300 个存储过程和视图，其中：
约 40% 可以直接或小改迁移
约 45% 需要重写逻辑
约 15% 是依赖 Oracle 特有特性（CONNECT BY、Model 子句、物化视图的自动刷新机制），需要在应用层重新实现
这部分工作量原本估了两周，实际用了六周。
坑 2：数据迁移不是一次性的
很多人以为迁移数据就是"导出→导入"，实际上是一个持续的工程问题：
存量数据的全量迁移（一次）
迁移期间业务继续产生增量数据的同步（持续）
迁移完成后的数据一致性校验（反复）
上线切换时的最终增量追平（时间窗口极短，压力极大）
这里我们踩的最大的坑是低估了 Oracle 到 PostgreSQL 的字段类型映射复杂度。Oracle 的NUMBER类型在 PG 里对应什么？DATE包含时间部分在 PG 里又是什么？VARCHAR2的长度语义是字节还是字符？
这些问题，在测试环境里没发现，在生产数据里被大量踩到。
坑 3：实时同步是整个项目最脆弱的环节
迁移期间，我们需要 Oracle 和目标数据库同时在线，通过 CDC 实时同步保持数据一致。最初的方案是用 Oracle GoldenGate——然后发现那是另一张 Oracle 的账单。
最终我们换成了 FineDataLink，专门负责迁移期间和迁移后的数据同步这条命脉。
原因有几个：
一是 FineDataLink 5.0 对 Oracle 的 CDC 支持独立做了优化——新增了独立日志解析模式，不再完全依赖 LogMiner。LogMiner 是什么？就是 Oracle 自带的日志读取接口，但它有个著名的缺点：性能差，且对源库有不小的负担。FineDataLink 5.0 的独立解析模式在大表场景下的同步延迟从分钟级压缩到了秒级，这对我们"迁移期间业务不停"的要求来说是决定性的。
需要数据集成工具FineDataLink 5.0的可以自取：https://s.fanruan.com/tx4dw（复制到浏览器）
二是自动 DDL 同步。迁移期间我们的开发还在继续，源库的表结构会有变化——加字段、改类型、偶尔删字段。每次结构变更都手动同步到目标库，一次两次还好，时间长了就是灾难。FineDataLink 5.0 支持自动同步 DDL 变更，源库改了字段，目标端自动跟上，不需要人工介入。
三是断点续传和异常恢复。网络抖动、目标库写入压力过大、偶尔的主机重启——这些在六个月里都发生过。每次都能从断点恢复，没有发生过需要从头重跑全量同步的情况。
坑 4：切换窗口永远比预期短
我们计划的切换窗口是周六凌晨 2 点到早 8 点，6 小时。
实际情况：前三次演练分别用了 9 小时、7.5 小时、7 小时。最终正式切换，用了 6 小时 40 分钟。超时了，但没有超太多——代价是那天早上推迟了两个小时开放系统，给所有业务部门发了一封道歉邮件。
四、迁移完成后，发生了什么变化？
迁移结束三个月后，我们做了一次复盘。
迁移前后关键指标对比（迁移完成 3 个月后）
成本那一项不用多说，是最直接的回报。
查询性能的提升超出了我们的预期。ClickHouse 的列式存储对分析查询的加速是数量级的——原来跑 60 秒的大宽表聚合，现在 3–5 秒出结果。这个变化对业务分析师的日常工作影响很大，他们开始愿意自己去查数据了，而不是等 DBA。
数据接入效率的提升，很大程度上来自 FineDataLink 的持续使用。迁移完成后我们没有停掉它，而是把它作为日常数据集成平台继续运营。新业务系统上线，需要把数据打通到数仓？以前是写接口、找 DBA、等排期，现在是在 FineDataLink 里拖拽配置一个 CDC 管道，最快半天完成接入。
5.0 版本里新增了 SaaS 应用连接器，我们用来接入了飞书多维表格和金蝶云星空——这两个系统此前完全是数据孤岛，现在已经和数仓打通，销售数据和财务数据终于能在同一张报表里看到了。
五、"值吗"这个问题，现在我怎么回答？
值。但不是因为我们运气好，而是因为我们把迁移当成了一个工程项目来管理，而不是一次临时的技术操作。
区别在哪里？
最后一点尤其重要。迁移不是终点，是起点。
很多团队迁完之后，原来 Oracle 时代那套"DBA 手动管一切"的习惯没变，只是换了个数据库继续手动管——数据质量没有检测，血缘不清楚，新系统接入靠写脚本，出了问题还是靠人肉排查。
我们现在用 FineDataLink 做的事情，远不止数据迁移：每天有定时任务在跑数据质量检测，发现异常自动通知对应的数据负责人；新业务系统接入有标准化的流程，不靠个人经验；数据血缘可以一键追溯，从分析报表追到源表、追到 ETL 任务节点。
这些不是花哨的功能，是让"迁移"变成"升级"的核心差距。
六、如果你也在考虑迁移，几个建议
Oracle 迁移启动前的必要检查项
先算账，再做决定
把 License 费、年维护费、专用硬件、DBA 溢价一起算，看 ROI 回收周期是否在 2 年内
摸清存量 SQL 的复杂度
重点看存储过程、视图、Oracle 特有语法的数量，这决定了迁移的实际工作量下限
迁移期间数据同步是核心风险
停库迁移在业务系统上几乎不可行，必须有实时 CDC 同步能力托底，GoldenGate 很贵，FineDataLink 是更低成本的替代
切换窗口要演练至少三次
没有演练的切换计划不可信，每次演练都会暴露新问题
迁移后治理比迁移本身更重要
数据质量、血缘追踪、新系统接入标准化——这些做好了，迁移才算真的值
Oracle 不是坏产品，它在特定时代解决了特定问题，解决得很好。但当"续费"变成一种惯性、当"被锁定"成为日常、当新的技术可能性被一张 License 单挡在门外——那个问题就值得认真问一遍：
我们真的还需要它吗？
我们问了，然后花了六个月找到了答案。
使用)