现在不仅国产数据库市场太卷了，甚至连吐槽国产数据库也开始卷了起来了，很多内容已经被多次吐槽，没有新意了，因此吐槽也要出新了。最近这段时间吐槽国产数据库的Oracle兼容能力的文章多了起来。认为国产数据库中提供其他 数据库的兼容性会增加数据库的复杂性，影响数据库的稳定性。有些吐槽也是有些道理的，不过与Oracle的兼容性是市场的刚性需求，而不是数据库厂商单边的意愿。最近在一些数据库选型中，与Oracle兼容性好的数据库产品往往会占有先机。
前几天有个吐槽就有点让人哭笑不得了，有人吐槽Oceanbase数据库的Oracle租户模式下的错误号与Oracle数据库兼容的问题，认为既然是国产数据库为啥还要当Oracle的舔狗，甚至连错误代码都要和Oracle搞兼容。认为这种做法非但没有好处，一不小心OB的应用报错被错当Oracle数据库报错了，还会引起不必要的误会。
我不知道这个哥们是在什么应用场景里把OB的报错当成了Oracle报错，导致了排查故障出现了偏差，因此才会发出如此的吐槽。
在obclient中连接到Oracle租户的时候，某些报错信息确实会完全模仿Oracle，比如上面的这个ORA-00942。这样的设计是为了让Oracle兼容模式对Oracle用户更友好。花钱买带有Oracle兼容租户的商用版的用户，大多数还是为了能够更加轻松的把以前的应用从Oracle迁移到OB上。如果说这种设计会引发不必要的误会，这件事本身来说就有些奇怪了。实际上在应用系统系统中看到的完整的错误信息应该是这样的：
ErrorCode = 942, SQLState = 42S02, Details = ORA-00942: table or view 'SYS.TST1' does not exist
这里面包含三个信息，错误号是942，SQLState是42S02（这是OB内部的错误位置），错误信息是ORA-00942。这个完整信息的格式与Oracle还是不同的，有Oracle开发经验的人一般很难弄混。
OB在错误代码上与Oracle做兼容是不是个问题？OB有MySQL兼容和Oracle兼容两种租户，在Oracle兼容租户模式下，错误信息显示与Oracle保持兼容，在MySQL兼容租户下，错误信息显示与MySQL保持兼容。这种兼容是为了将Oracle应用或者MySQL应用向OB迁移的时候尽可能少地修改应用代码，也可以让这两种数据库的DBA能够沿用他们以往的知识，是利大于弊的。
作为一个二十多年的Oracle DBA，我还是挺喜欢这种兼容的，很多常见的Oracle 错误代码已经深深印在脑子里了，如果看到一种新的数据库的新的错误代码体系的时候，只能去网上查一下或者翻手册，而如果错误代码与Oracle保持兼容，那么就省了重新记忆的过程，自然是一件好事情。
实际上Oceanbase数据库内部的错误号体系并没有根据Oracle的错误号体系来重新设计，只是在个别错误号的编排上特别考虑了与Oracle及MySQL的一致性，从而方便用户。架构完全不同的数据库，想要使用相同的错误号体系是不大现实的，大部分错误号肯定也是不同的。
国产数据库要完全照抄Oracle的错误编码体系，成本不是一般的高，没有哪个数据库架构师和产品经理会干如此疯狂的事情。一般情况下也仅仅是针对某些常见错误号做适应性的匹配，这种做法一般难度不是很大，达梦等数据库在这方面做得就很不错。
Oceanbase做兼容性支持就要复杂一些，因为目前Oceanbase有MySQL、Oracle两种兼容性租户，同一个错误点在这两种兼容模式下，错误代码是不同的。从Oceanbase的号段表上看，1-3999是预留给数据库兼容模式的，不同的租户类别含义不同，不过都尽可能与相兼容租户的数据库保持一致。上面的942错误实际上是一个兼容错误号，并不是OB内部真实的错误号。而内部的错误号为SQLState = 42S02，也就是42S02：
ERROR 1109 (42S02) : Unknown table '%.*s' in %.*s
OceanBase 错误码：5200
兼容 MySQL 错误码：1109
OB数据库内部的错误点是42S02，对应的OB错误号是5200（不同版本可能不唯一），如果是MySQL兼容租户，则会报错信息会是如下的，错误号为1109。
OB的这种在租户兼容模式下，部分错误号显示与相兼容数据库相似的做法是为了让用户降低学习难度，减少应用迁移的工作量。不知道各位朋友怎么看待这件事，我个人感觉，这是好事，不应该被吐槽。因此在这件事上，我站在OB这边。
