前阵子一个数据库原厂的售后人员和我聊天的时候说，好像我们这批老ORACLE DBA更能理解和包容国产数据库的现状。我说当然，现在的年轻DBA都只见过一个超级牛X的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问题了。
说起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也是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除了要拥有过人的技术之外，还得拥有过人的胆识。就像我这个哥们，在一堆领导的注视下，居然能够不停歇的敲了十几分钟命令。这种素质如果换成我肯定能是不行的。在应对复杂问题的情况下，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花了二十多年时间，已经变得十分完美了，我们也应该给国产数据库几年成长的时间吧。
