这几年只要聊到国产数据库，必然会看到这几个字：兼容 Oracle。
宣传材料上写着"高度兼容 Oracle"，测试报告里写着"通过率 99%"，销售顾问笑着告诉你"基本上无缝切换"。
然后企业真的去迁移，结果各种事情跟"无缝"二字毫无关系。
开始前，先送给大家一套数据仓库建设资料包，里面包含了数仓的技术架构、数仓建设关键点、数仓工具等内容，可以帮助大家更全面、深入地理解数据建模：https://s.fanruan.com/tyac0(复制到浏览器)
一、"兼容 Oracle"到底在兼容什么
说"兼容 Oracle"之前，得先搞清楚 Oracle 本身有多少层。
语法层：SQL 语法、函数名、关键字。这一层是最容易"兼容"的，也是很多厂商测试的主要对象。
行为层：同样的 SQL 在两个数据库里执行，结果是否一致？NULL 值的处理方式是否相同？隐式类型转换的规则是否一致？字符串截断时是报错还是静默截断？这一层开始出现分歧。
特性层：存储过程、函数、触发器、序列、包（Package）、游标、DBLINK、物化视图、分区表、RAC 集群、闪回查询……Oracle 特有的功能体系，哪些支持，哪些不支持，哪些行为不一样？
生态层：连接驱动、连接池、ORM 框架、三方工具、备份恢复工具、DBA 的操作习惯……
大多数国产数据库说的"兼容 Oracle"，主要集中在语法层，在行为层和特性层就开始有各种差异，生态层更是各有各的情况。
"兼容 Oracle"这句话本身没有错，问题在于它没有说清楚兼容的是哪一层，兼容到什么程度。
二、语法兼容 ≠ 行为一致
举几个真实场景。
空字符串和 NULL 的处理。Oracle 里空字符串和 NULL 是等价的，'' = NULL为真。但在 PostgreSQL 系的数据库里，空字符串就是空字符串，和 NULL 是两回事。如果应用代码里大量用空字符串来判断"未填写"，迁移过来之后查询结果就会不对。
隐式类型转换。Oracle 在某些场景下会自动把字符串转成数字，或者把数字转成日期。国产数据库在类型转换上的行为不一样，可能直接报错，也可能返回不同的结果。
日期格式的默认行为。Oracle 默认日期格式是DD-MON-RR，很多系统直接依赖这个默认值。换了数据库，如果没有显式指定格式，日期处理逻辑就可能悄悄跑错。
ROWNUM 和分页。Oracle 用 ROWNUM 做分页是经典写法，但 ROWNUM 的计算逻辑和 LIMIT/OFFSET 并不完全等价，复杂嵌套 SQL 里的 ROWNUM 迁移改写是一件耗费大量精力的事。
这些问题不会在功能测试里直接报错，只会在业务数据跑起来之后，以各种形式的"结果不对"出现。
三、存储过程和触发器，是最容易踩坑的地方
如果说语法兼容只是"表面功夫"，那存储过程、函数和触发器就是真正的硬骨头。
Oracle 里的 PL/SQL 是一套成熟的过程化语言，有完整的异常处理机制、游标操作、包结构、自定义类型和大量内置函数。很多企业的核心业务逻辑，包括审批流程的触发规则、库存计算逻辑、财务凭证生成、报表汇总计算，都是用 PL/SQL 写的存储过程。
这些存储过程在 Oracle 上跑了多年，稳定可靠，改动风险高。
换了数据库，不管对方说自己多兼容，PL/SQL 的迁移基本上都需要人工介入。有些语法可以机械转换，有些逻辑需要重写，有些行为差异需要测试验证。一个核心系统的存储过程改写下来，往往比重新写一遍还麻烦，因为你得搞清楚原来的逻辑是什么，然后再想怎么在新数据库上实现相同的效果。
触发器也是类似的问题。很多系统的数据一致性逻辑是靠触发器保证的，迁移时要么改写触发器，要么把逻辑迁移到应用层——无论哪种，都不是小工程。
四、99% 兼容和 100% 兼容之间，差着一个生产系统
有人问：差那 1%，有多严重？
这取决于那 1% 在哪里。
如果那 1% 是很少用的冷门函数，可能没什么影响。
但如果那 1% 是某个核心财务系统每天运行几百次的存储过程，是某个生产管理系统实时触发的触发器，是某个报表系统依赖的特定 SQL 行为——那 1% 就能让系统停摆。
不是在夸大问题，现实项目里确实发生过这类情况：
在测试环境里跑了几千条 SQL，通过率 98%，判定可以上线；上了生产之后，那 2% 里有一条是月结凭证生成逻辑的核心函数，当月所有凭证全部报错。
数据库替换的风险，不能用"通过率"来衡量，要看那些没通过的地方具体是什么。
五、Oracle 为什么还活得这么好
在国产替换喊了这么多年之后，Oracle 在金融、央企、电力、制造这些行业的核心系统里，装机量还是相当可观。
原因很简单：不是"换不了"，而是"换了之后要承担的风险和成本，不比继续用贵"。
历史负债太重。一个用了十几年的 ERP 系统，里面有几百个存储过程，几十个定制化的触发器，和三十个依赖特定 Oracle 行为的定时任务。这些都是业务知识，不是简单的技术问题，改写需要了解原始逻辑，测试需要覆盖所有业务场景。
替换成本不只是数据库许可费。改写代码、测试验证、数据迁移、人员培训、运维体系重建，加起来可能远超若干年的 Oracle 许可费用。
稳定性的代价是时间积累。Oracle 跑了十几年没出问题，换了新数据库之后，新的边界问题、性能问题、偶发故障都需要时间磨合。对于业务连续性要求很高的系统，这个磨合期本身就是风险。
所以你会看到一个现实情况：很多企业选择"新建系统用国产，老系统继续用 Oracle，等老系统自然更替的时候再做迁移"。这不是不思进取，是在做合理的风险评估。
六、异构共存阶段，数据怎么流
在 Oracle 和国产数据库并存的阶段，最头疼的问题之一是：数据怎么在两边之间流转？
有些企业在迁移过程中需要让 Oracle 和新数据库同时运行一段时间，做数据一致性验证——Oracle 里写入的数据，要同步到新数据库，然后对比两边查询结果是否一致，才能判断迁移是否可信。
这个过程涉及几件事：
把 Oracle 的存量数据全量导入新数据库；
在迁移窗口期，Oracle 的增量变更实时同步到新数据库；
处理两端的字段类型差异：Oracle 的 NUMBER(10,2) 到新数据库可能要映射成 DECIMAL(10,2)，DATE 类型的精度行为不同，CLOB 和 BLOB 的处理方式也可能有差异；
对比两端数据，做记录数、主键、金额汇总等校验；
跑通后切换，迁移后继续监控一段时间。
FineDataLink 5.0 在这个场景里可以起到比较关键的作用。它同时支持连接 Oracle、达梦、OceanBase、GaussDB、人大金仓、TiDB 等数据库，可以用实时管道任务拉取 Oracle 的 CDC 变更日志（LogMiner 或 OGG-Kafka 两种方式均支持），做增量同步。在字段映射这一层，5.0 版本进一步完善了字段类型映射规则，可以在连接时统一处理日期格式、字符集、NULL 值行为等差异。
数据迁移完成之后，FineDataLink 内置的数据检测任务可以对源端和目标端做一致性校验：记录数是否匹配、主键是否重复、金额汇总是否一致、关联字段是否完整。5.0 版本新增的"数据一致性检测"功能可以定期自动运行检测，而不只是迁移的时候手动跑一次，当检测不通过时主动通知运维人员，发现问题在业务感知之前。
七、国产数据库的替换路径，应该怎么走
说了这么多问题，并不是说国产数据库替换 Oracle 是不可能的事。
事实上这几年国产数据库在技术层面进步相当快，达梦、OceanBase、GaussDB、TiDB、人大金仓在各自的场景里都有真实落地案例，而且随着 Oracle 版本停止维护、安全合规要求和国产化政策的推进，替换是迟早要发生的事。
问题不是"能不能替换"，而是"怎么替换才不出事"。
比较稳妥的路径大致是这样的：
新建系统直接用国产数据库，从一开始就不引入 Oracle 依赖，这是最干净的做法。
对于已有系统，先从非核心、复杂度低、存储过程少的系统开始替换，积累经验，建立迁移方法论和测试体系。
核心财务系统、核心生产系统这类历史负债重、业务影响大的系统，留到最后，等前面的系统替换完成、团队有足够经验之后再动。
在这个过程中，不要被"99% 兼容"的数字迷惑，要把剩下的 1% 弄清楚，看它落在什么地方。
尾声
"兼容 Oracle"这句话，本身没有问题。
问题是很多厂商用它来暗示"切换成本很低，基本上无缝替换"，而实际情况是，替换成本的大头不在数据库本身，而在业务逻辑、存储过程、触发器、历史数据和整个测试验证的过程。
国产数据库在进步，Oracle 替换是大趋势，但这件事需要严肃对待，不能靠一句"高度兼容"就把风险掩盖掉。
搞清楚那 1% 在哪里，比知道 99% 通过率更重要。
