从写代码到管Oracle，路上那些坑和成长的故事

让我想起了自己刚入行那会儿,真是又菜又爱玩，踩的坑能把自己埋起来，最开始，我就是个写代码的，觉得把功能实现、代码写得漂亮就行了，数据库？那不就是个存东西的地方嘛，连一连，执行个SQL，能有多难？这种想法，在我第一次真正接手一个重要的Oracle数据库管理任务时，被击得粉碎。

我记得特别清楚,那是我工作第三年，公司一个核心业务系统，用的是Oracle，原来的DBA（数据库管理员）突然离职了，一时半会儿招不到人，领导看我平时还算踏实，就说：“小张，你先顶一阵子，主要是做些简单的日常维护和备份。”我当时心里还挺激动，觉得机会来了，能接触到公司最核心的数据资产。

结果,“顶一阵子”的第一个星期，我就差点捅了个大篩子，事情是这样的，业务部门反映某个查询页面特别慢，我登录到服务器上，用top命令一看，CPU都快飙到100%了，我当时的第一反应和很多程序员一样：肯定是某个SQL语句写得不好，有全表扫描，于是我摩拳擦掌，找到了一个看起来执行时间很长的SQL会话，想都没想，直接一个ALTER SYSTEM KILL SESSION就把人家的会话给杀掉了。（这个操作后来被我的导师称为“野蛮操作”）

我以为问题解决了,正有点小得意，没想到五分钟不到，业务部门的电话就打爆了，说整个系统都卡死了，完全没法用，我当时冷汗就下来了，手忙脚乱地连上去，发现数据库几乎停滞了，后来才知道，我杀掉的那个会话，是一个非常重要的月度报表生成进程，它之所以慢，是因为在处理海量历史数据，而且它开启了事务，持有锁，我粗暴地杀掉会话，导致事务没有正常结束，锁没有被释放，进而引发了大规模的锁等待，就像公路上一个关键路口发生了车祸，把后面所有的车都堵死了。（这个比喻是我后来在Oracle的官方文档里看到的，当时觉得特别形象）

那次故障持续了半个多小时,最后是在一位远程支援的老法师指导下，我战战兢兢地通过查询数据字典找到那些被挂起的锁，手动清理掉的，虽然最后系统恢复了，但我被领导叫去办公室狠狠批了一顿，那是我职业生涯第一次感到如此巨大的压力和挫败感，我明白了，管理生产数据库，尤其是像Oracle这样复杂的系统，远不是会写几句SQL那么简单，它需要你对事务、锁、内存结构、I/O原理有深入的理解，你的每一个操作都必须是谨慎的、可逆的、有预案的。

从那以后,我收起了自己的傲慢，我开始像海绵一样学习，白天处理日常工作，晚上就啃Oracle官方厚厚的概念手册、管理员指南，我加入了几个技术论坛，看那些资深DBA是如何分析问题的，我意识到，不能等到出问题了再当救火队员，得防患于未然，我学着搭建监控系统，监控数据库的性能指标，比如等待事件、逻辑物理读写、表空间使用率等等，我开始制定严格的变更流程，任何对生产环境的操作，哪怕是加个索引，都必须先在其他环境测试，然后写好回滚方案，在业务低峰期进行。

大概过了一年多,我才感觉自己算是勉强“入门”了，我不再是那个只会用代码思维考虑问题的程序员，开始有了全局的、运维的视角，我会在项目设计阶段就介入，和开发同事讨论表结构设计是否合理，索引怎么建，会不会有并发问题，这种转变是潜移默化的，有一次，一个新来的同事写了一个复杂的更新语句，自认为效率很高，我看了执行计划后，告诉他这个语句在数据量大的时候可能会引起严重的闩锁竞争，建议他换一种写法，他当时将信将疑，但测试后发现果然如此，那一刻，我心里有种说不出的成就感，感觉自己踩过的坑、熬过的夜，都值了。

现在回想起来,从写代码到管理Oracle，这条路其实就是从一个点的技能，扩展到一个面的知识体系的过程，代码是微观的实现，而数据库管理则是宏观的保障，那些曾经让我狼狈不堪的“坑”，比如那次鲁莽的杀会话、一次因为表空间不足导致的宕机、一次因为备份策略不合理差点无法恢复数据的惊魂……都成了我最宝贵的经验，它们让我懂得了敬畏之心，也让我成长为一名更全面、更负责任的技术人，这条路没有捷径，就是不断学习、不断踩坑、不断总结。