前段时间，一家原数据库工厂的售后人员跟我聊天时，似乎我们老甲骨文DBA更能理解和容忍国产数据库的现状。 我说当然，现在的年轻DBA只见过超级牛xOracle数据库，这就像我们被Oracle滥用得淋漓尽致。他们不知道，数据产品在越来越好之前，会经历一个难以忍受的童年，国产数据库也是如此。
甲骨文的苦涩过去
诚然，甲骨文并不是天生就像现在这样优秀，当我第一次开始使用甲骨文时，甲骨文就像一个仍然又爱又恨的渣男。 就算不提难以忍受的90年代，也只是一个相对靠谱的Oracle 92 说到那个时代，当时的甲骨文的过去对于DBA来说也是非常凄美的。
oracle数据库运行平稳，永不宕机这不适合十几二十年前的场景。当时，有太多的事情，比如数据库宕机、重启、挂起，以及使用速度太慢。 数据库重新启动并且一小时或半小时没有关闭的情况并不少见。 而且因为当时对oracle数据库的原理了解不多，甚至不知道为什么关不掉也起不来，也不敢随便操作，甚至有些用户也不敢轻易关闭或重启数据库。
面对莫名其妙的挂起的无奈，或者一个数据库太慢而无法使用，仍然经常被记住。 CBC 闩锁、缓冲繁忙等待、无闩锁、...，这个问题会让DBA忙上半天。 更不用说是共享池、库缓存锁定还是 ora-4031 问题。
ORA-1591 错误
当我想到甲骨文难以忍受的过去时，首先想到的是 ORA-1591 错误。 能一下子分辨出问题所在，估计至少有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强制回滚或提交相关的本地事务。 这是我差不多二十年前半夜被吵醒后最常遇到的问题。 大多数用户可以在远程指导下在十几到二十分钟内解决问题。 甲骨文的这个问题很烦人，但它也让我时不时地发财。
ORA-1578 问题
Ora-1578 也是 Oracle 用户的常见问题。 当时 Oracle 数据库的 bug 太多了，数不清，最头疼的就是可能导致逻辑坏块的 bug，起初我以为坏块是硬件造成的，但后来我发现 oracle bug 产生逻辑坏块的几率远远大于硬件。 一旦出现逻辑坏块，就必须使用DBMS修复来修复，唯一无法修复坏块的工具就是使用这个工具强制将该块标记为坏块，否则在进行全表扫描时会报SQL错误。 当时，该应用程序写得非常糟糕，几乎不可能避免全表扫描。
一些逻辑坏块不以 ORA-1578 的形式报告，但有时会出现ora-600[kcbgtcr_x]这也意味着应用程序会扫描逻辑坏块。
有一次，一个哥们为操作员做了 9 个2.0.2 至 92.0.5 次升级。 升级后的第二天，数据库开始报告大量 ora-600 错误。 好友还在睡梦中被用户叫到现场，在IT部门大大小小的领导的注视下坐在终端前，脑子一片空白。
事后，他心悸地对我说，他当时脑子一片空白，不知道该如何分析这个问题，但是在那么多甲方领导的注视下，他不能傻傻地坐在那里什么都不做，于是不停地在SQLPLUS中输入所谓的SQL语句来拖延时间。 因为他在路上的时候叫我**，他知道自己在场上的所有工作都没有任何希望，他唯一能指望的就是我在远处帮他查元链接。
那天我很幸运，他在键盘上打了十多分钟后，我发现了一个类似的bug，我的**救了他。 当时我们俩都不确定是否是这个错误导致了 600 错误，但别无选择。 幸运的是，玩完这个补丁后，错误实际上消失了。
Oracle DBA 的不同之处
在那些难以忍受的岁月里，作为一名 Oracle DBA除了拥有过硬的技术，还必须有非凡的勇气。就像我的朋友一样，在一群领导的注视下，他能够不停地打订单十多分钟。 如果这种品质被替换，我肯定做不到。
在处理复杂问题的情况下，DBA 必须具备多项独特的技能。 例如，您可以读取和分析告警日志、分析系统状态转储、执行挂起分析以及查看操作系统日志。 数据库挂起，sqlplus无法登录数据库，你还有办法做挂起的诊断吗？没有掌握sqlplus -prelim 'as sysdba'技能的人，遇到这样的问题会麻木
如果遇到ORA错误或ORA-600错误，是否可以根据错误号大致确定故障范围？在那些日子里，我敢说我是这方面的大师，每天必须多次浏览错误段表，这让我对这些错误非常敏感。
前两天，有朋友在群里问了一个错误信息，我很多年没有在一线做运维了，但是基于20年的机械记忆，没有翻过数据，我很快就给出了一个大致的方向，没想到竟然是对的。 对于被Oracle数据库折磨多年的老DBA来说，这方面有一些特长。
总结
Oracle 并不是天生的好数据库，宕机、bug、坏块、GCS GES、共享池、挂起和不可用也时不时地困扰着 DBA。 然而，问题严重的Oracle培养了大量极高级别的DBA。 二十年前，我经常帮助一些国外DBA解决MSN上的一些难题。 曾经有个外国人问我，你应该是中国最好的Oracle DBA。 “我回答说：”没关系，它比最好的DBA差得多。 他最后说：“中国的DBA太好了”。
现在我们面对的国产数据库也像预言机那不是超级厉害的那么多问题，前段时间我听到一位朋友评论国产数据库，“自主研发都是bug，基于开源并不新鲜”，非常鄙视国产数据库。 数据库等复杂的基础软件系统，必须在使用大量用户的过程中不断完善，才能消除大量的软件bug，最终逐渐成熟。 甲骨文花了20多年的时间，已经变得十足了，我们也应该给国产数据库几年的时间来成长。
作者丨白鳗**丨***白鳗洞 （ID： baishan755） DBAPLUS社区欢迎技术人员投稿，投稿邮箱：editor@dbapluscn