• 2019年10月9日，某部委人士在公开会议上指出，“OceanBase测试指标虽高，但在关键领域仍不能使用”、“互联网和银行场景完全不同”、“不能支持跑批（批处理业务）”。问题本质是“什么样的分布式数据库在关键领域可用”？
• 从用户的角度，答案很明确，兼容Oracle功能且满足性能要求。兼容Oracle，意味着“不改造应用系统无缝升级模式”，用户责任小，风险低。满足性能要求，意味着业务可运行。

       那OceanBase是不是这样一个产品呢？

       先说Oracle的兼容性：

       1）数据库核心功能，OceanBase在分布式架构下，不兼容Oracle的存储过程、触发器、视图、多表关联、大表关联等常用数据库核心功能，需要通过大规模改造应用系统来弥补功能缺口，工程繁复，且不保证改造一定成功；

       2）隔离等级，OceanBase不支持Oracle的隔离等级“可重复读”，存在不可知数据错误风险及高失败率；

       3）锁机制，和Oracle严苛锁机制相比，OceanBase是松散锁机制，在有数据冲突的金融场景，必然导致跑批（批处理业务）中断，存在业务连续性风险；

       结论，OceanBase完全不兼容Oracle，其缺口源于结构性差异，不可能通过适配解决。

       再说性能，分布式数据库性能的关键是处理分布式事务的效率：

      1） 两次tpc-c测试，分布式事务均不是由OceanBase数据库完成的。按tpc-c规则，存在随机15%和1%跨仓交易，如果完全随机，总交易量的6.896%，即8小时共有520.017798亿个交易，成为跨数据库节点的分布式事务。蚂蚁金服披露“OceanBase1557节点集群时，压测tpmC/理论tpmC=0.987”，集群与单机相比性能0损耗，即分布式架构却完全没有分布式开销，显然tpc-c测试里的分布式事务不是由OceanBase数据库节点完成的。

      2）2019年6月，中国信通院和中国软件评测中心搞过一次分布式数据库的公开摸底考试，不允许大规模修改应用系统，OceanBase性能不佳，没有进入复试。

       3）支付宝场景，有专业人士认为：“网络支付场景，更多是连接，而资金的清算早期在商业银行，现在在人行网联平台，而非支付公司。相反，说明银行的核心系统大有进步。”支付场景与金融场景差异明显，OceanBase分布式事务能力仍需证明。

       4）OceanBase多个外部测试场景，目前均未见到OceanBase单独完成分布式事务，更多是由应用系统分担，OceanBase作为数据存储。

       5）高斯分布式数据库与OceanBase同属一类，实战效果不佳，已下架。

       小结，没有直接证据证明OceanBase分布式事务处理性能。

       综上所述，OceanBase完全不兼容Oracle，分布式数据库性能尚待证明。结构上更像是一个数据库存储而非完整数据库，就像没有发动机的裸底盘，替换高端整车Oracle缺乏理论支撑和实践证明。

       以上观点均可快速验证，当众迁移一简单Oracle系统即可，如某标准OA。