我做DBA十一年。 经历过三次数据库国产化替换项目，主导过两次，其中一次中途叫停，一次延期八个月上线。我不反对国产数据库，我也不是Oracle的信徒。我只是在太多场合，听过太多次同样的话，然后在心里笑了又笑，却只能保持一个礼貌的表情。 这篇文章，是我多年来攒下来的那些笑意。 也正因为踩过这些坑，我现在看国产化项目，更关心迁移过程中那些真正容易出问题的环节：异构数据库怎么稳定同步、Oracle日志解析会不会影响源库、双轨运行期间数据怎么持续校验、国产数据库之间的数据链路怎么接。 工具能解决的当然不是全部，但有些坑，确实没必要再靠人肉去填。像我们实际做数据迁移和同步时会用到的 FineDataLink 5.0，现在针对 Oracle 日志解析、国产数据库同步、实时数据处理和数据质量校验都补了不少能力。尤其在国产化项目里，它更像是把"迁数据、追增量、核数据"这一段脏活累活尽量工程化，至少不用所有问题都靠脚本、Excel和DBA自己盯。

"我们的兼容性达到99%" 我第一次听到这句话，是在一场技术选型会上。 对方PPT做得很精良。兼容性测试报告密密麻麻，数字是99.7%。我坐在台下，脑子里只有一个问题：那0.3%是什么？ 会后我专门去问了驻场工程师。他想了一下，说："主要是一些高级特性，您的业务应该用不到。" 后来我们上了项目。那0.3%里，有我们系统里跑了七年的一个核心存储过程用到的特性。 改写花了六周。 "您的业务应该用不到"，这句话的意思是：我不知道您的业务用不用得到，但我希望您用不到。99%的兼容性，剩下那1%是薛定谔的状态——在你真正开始迁移之前，没有人知道那1%里藏着什么。

免费试用

"我们有完整的生态" 这句话我每次听到都想问一个后续问题，但通常没有机会问完。 "完整的生态"，具体是什么？监控工具、备份工具、运维管理平台、性能诊断工具——有，但大多数是厂商自己出的，或者合作伙伴出的，成熟度参差不齐。跟Oracle的AWR报告比、跟Oracle Enterprise Manager比、跟那个Oracle生态里跑了二十年、被几十万DBA反复打磨过的工具集比—— 不是不能用。是用的时候会不断遇到一些"这个功能我们下个版本会有"的情况。 我印象最深的一次，是在生产环境出了一个性能问题，需要做执行计划分析。用惯了Oracle的工具，换了国产库之后，找了半天才找到对应的诊断路径，文档写得语焉不详，最后是靠厂商驻场工程师远程指导才定位到问题。 这件事在Oracle上，我十分钟能搞定。 "完整的生态"，什么时候算完整？我理解的完整，是你能独立解决问题，不需要每次都等厂商来救场。这个标准，国产数据库里能达到的，目前还是少数。

"我们在您这个行业有很多成功案例" 听到这句话，我会做一件事：要案例清单。 通常厂商会给。然后我会逐一确认：这个案例，是核心交易系统还是边缘系统？上线多久了？数据量级是多少？并发峰值是多少？有没有踩过坑，踩的是什么坑？ 能回答完这五个问题的案例，往往剩下原来的三分之一。 不是说剩下的那些是假的。是说"成功案例"这个词的定义，太宽了。一个跑了三个月的内部报表系统，和一个跑了三年的核心账务系统，都叫"成功案例"。但它们代表的成熟度，不在同一个量级上。 有一次我拿到一份案例清单，翻了翻，发现同一家银行被三个不同的国产数据库厂商同时列为"成功案例"——厂商A说替换了他们的信贷系统，厂商B说替换了他们的风控系统，厂商C说替换了他们的报表系统。 三家说的都是真的。但如果你以为"这家银行已经全面国产化了"，那就是自己骗自己了。

"迁移很简单，我们有工具" 这句话我听到的时候，心里默默开始计时。 "工具"是真实存在的。SQL转换工具、Schema迁移工具、数据同步工具——都有。 其中有些做得相当不错。比如FineDataLink这类数据集成平台，在异构数据库之间做实时增量同步这件事上，确实把很多原本需要手写脚本才能搞定的链路给工程化了。 尤其是5.0版本里做的Oracle独立日志解析——这个功能值得单独说一下，因为它解决的是一个真实踩过才知道有多疼的问题：Oracle的LogMiner和XStream默认跑在源库的硬件资源上，业务高峰期源库本来就压力大，日志解析再来抢资源，轻则延迟飙升，重则源库卡顿影响上层业务。 独立日志解析把这个过程从源库剥离出去，放到独立节点上跑，源库的业务压力和同步的解析压力互不干扰。这不是锦上添花，是在高业务频率的迁移场景里，堵住一个随时可能炸掉的口子。这类工具能解决的部分，是真的能解决的。 但工具能解决的，是标准化的部分。 那些跑了十年的存储过程，里面有游标、有动态SQL、有Oracle特有的ROWNUM和CONNECT BY层级查询、有DBMS_开头的系统包调用——工具扫一遍，告诉你哪些需要人工处理。人工处理的那部分，才是真正的工作量。 我主导的那个延期八个月的项目，工具能自动转换的大约是六成。剩下的四成，是我们的开发团队一行一行改出来的。 "迁移很简单"这句话，对的。简单的那部分，确实简单。不简单的那部分，它没说。

"我们的性能经过专业压测，超越Oracle" 这句话有一个标准的配套动作：翻开一份压测报告。 报告通常很专业。TPC-C跑分、TPC-H跑分、QPS数字、延迟数字——都有。有时候确实比Oracle好看。 然后我会问：压测的数据量是多少？并发用户数是多少？硬件配置是什么？测试的SQL是业务真实SQL还是标准测试集？ 绝大多数情况，是标准测试集，是在一个比较理想的硬件配置下，用一个相对干净的数据集跑出来的结果。 我们生产环境的Oracle，跑着十三年的历史数据，有数百张表，表之间有复杂的关联关系，高峰期有几百个并发连接，查询里有大量的多表JOIN和子查询。 这个环境下的性能，和压测报告里的性能，不是同一回事。 "超越Oracle"——在什么场景下，用什么硬件，测什么SQL，跑多大数据量？这四个限定条件不说清楚，"超越"两个字就是一个悬在空中的结论。

"数据迁移完成，验证没有问题" 这句话出现在上线前的最后一次汇报里，语气通常很笃定。 我每次听到都想追问一句：验证了什么，怎么验证的？ 数据迁移的验证，是这整个过程里最容易被低估的环节。记录数对上了，不代表数据对了——字段类型隐式转换可能悄悄改变了数值精度，时区处理不一致可能让时间戳差了八个小时，字符集转换可能让某些特殊字符变成了乱码。这些问题不会在验证报告里主动出现，它们会在上线后的第一个月里，以各种奇怪的业务异常形式出现。 更难处理的是迁移后的持续数据质量问题。双轨并行期间，Oracle和国产库同时在写数据，两边的数据如果不能实时对齐、实时校验，发现问题的时候往往已经积累了大量脏数据，回溯成本极高。 这里有一个值得关注的细节： FineDataLink 5.0在数据质量这块做了完整性、一致性、准确性、唯一性、时效性、有效性六个维度的监控规则，能在数据同步过程中持续检测异常，发现问题直接通知对应负责人——不是等业务跑出问题才发现，是在数据流转的过程中就把坏数据拦住。 对那些在并行运行期神经高度紧绷、每天靠人肉抽查核对两边数据的团队来说，这种实时质量监控加上血缘分析定位上游问题源头的能力，是真正能减少凌晨报警电话的那种工具。 "验证没有问题"——迁移结束时的那次验证，只是起点，不是终点。

免费试用

这句话是真的。只是"支持"的响应质量，需要亲历才能理解。 提一个工单，系统会自动回复"已受理，预计4小时内响应"。4小时后，会有一个初级工程师来问你基本情况，让你提供日志。你提供了，他说需要转给专家组。专家组响应，通常是第二天。 这不是在抱怨服务态度——态度都很好，工程师也很努力。是在说，Oracle出了问题，你能在MOS（My Oracle Support）上搜到全球几十万DBA踩过的同款坑和对应解法。国产数据库出了问题，那个积累不在那里，需要厂商来填。 厂商填得动，只是需要时间。时间，在生产环境的故障窗口里，是最贵的东西。

说到最后 写这些，不是因为我觉得国产数据库做得差。 是因为这些话，把该有的期望设得太高，而落地的时候又让所有人都难堪。 最后吞下落差的，不是讲这些话的人。是凌晨两点在机房里盯着日志的人。是被追问"项目怎么又延期了"的项目经理。是那个不得不向业务部门解释"系统暂时有点问题"的技术总监。 国产数据库会越来越好。这件事我相信，而且是真心相信。 只是希望它好起来的速度，能追上那些话说出去的速度。 不然，听的人只能继续笑着点头。