经常有人给我留言说，十多年前传统Oracle DBA的技术已经过时了，云时代的DBA已经不需要那些所谓的高深的技术了，懂业务，会优化慢SQL就已经很优秀了。确实很多企业的信息系统经过了上云、中台和微服务化一阵折腾之后，因为数据库的问题而导致的严重故障少了很多，绝大多数情况下系统的问题出在应用、网络和云平台IAAS层上。在这种环境中，传统Oracle DBA的很多神鬼莫测的高级技能可能不见得能派上用场。

在这种意义上来说，技术是会过时的。我刚刚从事DBA工作的时候，遇到最多的比较难以解决的Oracle数据库问题是分布式事务两阶段提交失败导致的行锁无法解锁问题、索引重建或者创建时异常中断导致的锁表、数据库出现逻辑坏块应用报错，当时能够十分顺溜地处置这三大难题的DBA估计全国范围数一数，估计双手都数得出来。不过随着Oracle的发展，这些问题出的越来越少了。后来最容易出问题的就变成了ORA-4031、CRS节点reboot、RAC DRM REMASTER、LATCH FREE等问题了。在相当长时间里能够十分准确地定位共享池问题是高手的标配，不过这些年这些问题又很少见了。

技术可能看似会过时，不过技术的价值不会消亡。前阵子有个金融企业遇到了一个共享池的问题，Oracle 原厂定位和他们的应用有关，并且给出了解决方案，不过对应用调整较大，上线新模块需要点时间。在这段时间里如何临时性避免问题再次出现，我建议他们这几天累一点，每天晚上非业务高峰期purge掉出问题的共享池对象，然后跑一次这几条有问题的SQL，确认执行计划OK，这样第二天出问题的概率就比较小了。能想出这些歪主意是以对共享池和Oracle cursor机制的理解，并且拥有丰富的经验为基础的。这些平时没啥用的“屠龙技”的价值是一直存在的，如果需要用的时候找不到，也是会耽误事的。

哪怕是Oracle DBA中的高手，这二十多年来技术特征也是不同的。现在的Oracle DBA要求懂的技术范围很广，从10g到23ai都要能玩得比较溜，各种部署架构、高可用方案甚至一体机都能玩得很好，而具体某一点的技术不需要钻的特别深，而且以目前Oracle技术的广度，想要每个地方都很深入也是不现实的。不过不管技术如何发展，对DBA的需求如何变化，哪怕你在用MySQL,所从事的工作主要是让开发人员规范SQL编写和数据库设计，并且不断帮应用找出慢SQL并去优化它。高手和普通DBA也还是有差别的，工作成效的差别也不是一般的大。

DBA能力的高低取决于几个方面，人本身比较聪明，祖师爷赏饭可能是一个很重要的因素，不过在DBA行业里，勤能补拙的例子也是比比皆是的。DBA是一个无法在书本上快速成长的职业，必须在实战中摸爬滚打才能真正成为高手。不过仅仅依靠实战又不足够，没有充分的理论作为辅助，仅仅依靠实战也很难成为真正的高手，不断实践、不断总结，在实战和总结中发现自己的理论基础缺失，主动去学习，可能是每个高水平DBA都不断在重复的事情。