前阵子一个数据库原厂的售后人员和我聊天的时候说，好像我们这批老 ORACLE DBA 更能理解和包容国产数据库的现状。我说当然，现在的年轻DBA都只见过一个超级牛X的 Oracle 数据库，哪像我们有过被 Oracle 虐得体无完肤的经历。他们不知道数据产品都会经历不堪回首的童年，才能变得越来越好，国产数据库也是如此。
Oracle 辛酸往事
确实，Oracle 也不是天生像现在这么牛的，我刚开始用 Oracle 的时候， Oracle 也只像个仍然又爱又恨的渣男。哪怕不提不堪回首的90年代，只是从相对来说比较靠谱的 Oracle 9.2 时代谈起，那时候的 Oracle 往事对于 DBA 来说也是十分辛酸的。
Oracle数据库跑起来杠杠的，从来不宕机，这话不适合十多二十年前的场景。那时候数据库宕机、重启、HANG住、慢得不能用这种事情经历过太多了。数据库重启一下，一个小时关不掉，半个小时起不来也是常有的事情。而且因为当时对 Oracle 数据库的原理不太了解，连为啥关不掉起不来都不清楚，也不敢随便瞎操作，甚至有些用户都不敢轻易关闭或者重启数据库。
面对莫名其妙的HANG死或者慢得不能使用的数据库而束手无策的场景现在还经常被记起。CBC闩锁、BUFFER BUSY WAITS、LATCH FREE、…，哪个问题出现都会让DBA忙上半天一天的。更不要说是不是出现的shared pool、library cache lock、ORA-4031问题了。
ORA-1591错误
说起Oracle那些不堪回首的往事，我第一个会想起的就是ORA-1591错误。能够一下子反应出这是个什么问题的DBA估计至少也过了40岁了，因为从Oracle 10g以后，Oracle在分布式事务失败方面的自动处理能力就很强了。
而对于Oracle 8i、9i甚至更早期的用户来说，这可以说是一个噩梦。
那时候基于TUXEDO的XA分布式事务挺流行的，DBLINK也是开发人员常用的技术。对于两阶段提交来说，一旦分布式事务失败，那么数据库系统或者XA管理器应该自动回滚或者提交事务。不过早期的Oracle数据库这方面的处理能力很差，而且因为数据库本身也不够成熟，分布式事务失败的比例也挺高的。
如果分布式事务失败了，而且dba_2pc_XXX相关的数据字典不完整，那么数据库是无法自动回滚或者提交分布式事务的。如果正好其他应用需要访问这个处于未决阶段的数据时，ORA-1591错误就出现了。
一般情况下，数据库出问题，祭出重启大法就可以解决问题。不过ORA-1591这个分布式事务故障引擎的错误，并不会因为数据库重启而消失，很多用户反复重启数据库都无法解决这个问题。这时候只能手工将dba_2pc_pending等系统字典的数据补充完整，然后使用rollback force或者commit force强制回滚或者提交相关本地事务。这是差不多二十年前我最经常在半夜被吵醒后遇到的问题。大多数用户在远程指导下，花上十几二十分钟，就能解决问题。Oracle的这个问题虽然令人烦恼，不过也让我时不时借此发笔小财。
ORA-1578问题
ORA-1578也是Oracle 8、9用户经常会遇到的问题。那时候的Oracle数据库BUG多得数不清，最让人头疼的还是能够引发逻辑坏块的BUG，刚开始我还以为坏块都是硬件引发的，不过后来发现，Oracle BUG产生逻辑坏块的机会远远大于硬件。一旦出现逻辑坏块，就必须用dbms_repair去修复，无法修复的坏块只能用这个工具去将这个块强制标注为坏块，否则一旦做全表扫描操作的时候，SQL就会报错。那时候的应用写得很烂，想要避开全表扫描几乎是不可能的。
有些逻辑坏块还不是以ORA-1578的形式报出来的，有时候出现ORA-600[kcbgtcr_x]也意味着应用扫描到了逻辑坏块。
有一次一个哥们给运营商做9.2.0.2到9.2.0.5的升级。升级完第二天一上班数据库就开始大量报这个ORA-600错误。我哥们还在睡梦中被用户叫到现场，在IT部门的大大小小领导的注视下坐在终端面前，脑子里一片空白。
事后他心有余悸地对我说，他当时脑子里一片空白，不知道该如何去分析这个问题，不过在那么多甲方领导的注视下，他不能傻坐在那什么也不做，于是他不断地在SQLPLUS里敲着不知所谓的SQL语句来拖延时间。因为他在路上的时候给我打了电话，因此他知道他在现场的一切工作都是没有任何指望的，唯一能指望的就是我在远方帮他查metalink。
那天也算比较幸运，他乱敲了十几分钟键盘后，我找到了一个类似的BUG，我的电话解救了他。虽然那时候我们俩都不是很确定是否是这个BUG导致了这个600号错误，但是已经没有选择了。所幸的是打完这个补丁，错误居然消失了。
Oracle DBA的过人之处
在那些不堪回首的岁月里，作为一个Oracle DBA除了要拥有过人的技术之外，还得拥有过人的胆识。就像我这个哥们，在一堆领导的注视下，居然能够不停歇地敲了十几分钟命令。这种素质如果换成我肯定能是不行的。
在应对复杂问题的情况下，DBA都必须有几手绝活。比如阅读分析ALERT LOG，分析SYSTEM STATE DUMP，进行HANGANALYZE 分析，查看操作系统日志等等。数据库HANG了，SQLPLUS无法登录数据库，你还有没有办法去做HANG的诊断？sqlplus -prelim ‘/as sysdba’这种技巧都不掌握的人，遇到此类问题不就麻爪了？
遇到某个ORA错误或者ORA-600错误，能不能从错误号上大致判断出故障的范围区间？在那个年代里，我敢说我是这方面的高手，每天都要翻几遍错误号段表让我对这些错误十分敏感。
前两天一个朋友在群里问一个错误信息，我已经好多年没在一线干运维了，不过基于二十年的机械记忆，在没有翻资料的情况下，我很快就大体给出了一个方向，没想到还蒙对了。对于被Oracle数据库折磨了多年的老DBA来说，在这些方面都有些特长。
总结
Oracle也不是生来就是一个优秀的数据库的，宕机、BUG、坏块、GCS/GES、共享池、HANG死、不可用也曾时时困扰着DBA们。不过问题多多的Oracle培育了一大批水平极高的DBA。二十年前，我还经常在MSN上帮助一些国外的DBA解决一些棘手的问题。有一次一个老外问我，你应该是中国最牛的Oracle DBA了吧。我回答说：“只能算还行的，比最牛的DBA还差得很远”。他最后说了一句：“中国的DBA太牛了”。
现在我们面对的国产数据库也像还没有超级牛逼的Oracle一样问题多多，前阵子听一个朋友如此评价国产数据库，“自主研发的全是BUG，基于开源的了无新意”，对国产数据库甚为不屑。数据库这样复杂的基础软件系统，必须在大量用户的使用过程中不断地提升改进，才能消除大量的软件BUG，最终逐渐走向成熟。Oracle花了二十多年时间，已经变得十分完美了，我们也应该给国产数据库几年成长的时间吧。
作者丨白鳝
来源丨公众号：白鳝的洞穴（ID：baishan755）
dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn