技术人生——第2集：膨胀自信，午夜凶铃(原文)「链接」

1.苦学原理，知其所以

自从那次临危受命之后，我在团队里的角色悄然发生了变化。大家不再把我当成一个“懂点数据库的开发”，而是真正意义上的DBA。为了不辜负这份信任，也为了填补自己那点“三脚猫功夫”的知识空白，我做了一个决定：啃下Oracle的官方文档。

那是一段痛并快乐着的日子。我至今还记得那段独自“修炼”的时光：每天下班后，办公室里只剩下我一个人，电脑屏幕上永远开着官方的《Oracle Concepts》电子文档，它的每一个章节，我都恨不得逐字逐句地背下来；而手边，则放着被我翻得起了毛边的《Performance Tuning Guide》和那本被誉为“圣经”的《Expert Oracle Database Architecture》。就在主机风扇单调的嗡嗡声和窗外沉寂的夜色中，我一头扎进了那个由“Buffer Cache”、“Redo Log”、“Latch”和“Mutex”构成的、精密而复杂的知识海洋中。

起初，那些晦涩的术语和复杂的体系结构图让我头疼不已。很多个夜晚，我对着一个概念（比如晦涩难懂的“一致性读”）反复琢磨，却百思不得其解。但就像第一集里解决那个性能问题一样，我骨子里那股不服输的劲又上来了。我开始把官方文档当成“圣经”，一页一页地啃，一个概念一个概念地死磕。

渐渐地，奇妙的感觉发生了。当我终于理解了Oracle的CBO（成本优化器）是如何根据统计信息来选择执行计划时，我猛然回想起之前我解决的各种问题——哦，原来我当时只是“蒙对”了结果，其背后的原理竟是如此精妙！当我搞懂了数据库的MVCC（多版本并发控制）机制后，我才明白为什么我们的应用在读写数据时可以做到互不阻塞。

这种从“知其然”到“知其所以然”的顿悟，带给我的快感远胜于写出任何一个功能模块。我的角色认知，也从一个被动响应的“救火队员”，开始向一个渴望洞悉全局、防患于未然的“系统医生”转变。

2.技不压身，效能飞升

系统化的学习，让我对数据库的理解日益加深。而我过去几年的开发经验，此刻也变成了我作为DBA的一项独特“利器”。我发现，很多传统的DBA对数据库本身了如指掌，但对应用的逻辑、数据如何流转却不甚关心。而我，恰恰能打通这两者。我知道哪个应用在什么时间点会产生大量数据，哪个Job的逻辑可能会给数据库带来压力。于是，我的“老本行”——写代码，又派上了用场。我开始用Shell脚本编写各种自动化运维工具。与其说它们是工具，不如说是我的“智能助手”：

这些现在看来很基础的脚本，在当时那个“刀耕火种”的年代，却极大地提升了整个数据库管理的效率，将我从无数重复、枯燥的手工操作中解放了出来。领导在会议上不止一次地表扬我，说我把开发思维带到了数据库运维管理中，真正做到了“降本增效”。

那段时间，我几乎成了团队里的“效率之星”，同事们遇到问题也愿意来找我咨询。我感觉自己简直无所不能，职业生涯的“蜜月期”达到了顶峰。

3.水满则溢，月盈则亏

古话说，水满则溢，月盈则亏。当一个人的自信心膨胀到极点时，离犯错也就不远了。

随着对系统的日益熟悉和一系列自动化的成功，我开始觉得这套数据库系统已经完全在我的掌控之中。我不再满足于让它“稳定运行”，而是渴望让它“极致完美”。我像一个偏执的艺术家，审视着自己的作品，总想找到可以打磨得更光滑的地方。

很快，我找到了一个新的“优化点”。我注意到，系统在业务高峰期，log file sync这个等待事件时常会跳得很高。根据我在一些技术论坛上看到的“高手经验贴”，这通常和redo log的提交方式有关。那些帖子言之凿凿地宣称，通过调整一个关键的数据库参数COMMIT_WRITE，将其默认的IMMEDIATE（立即写入）改为BATCH,NOWAIT（批量、异步写入），可大幅降低这个等待事件，从而提升系统的TPS（每秒事务处理量）。

这个发现让我兴奋不已。我仿佛又找到了一个可以展现自己技术深度、让领导和同事们再次对我刮目相看的机会。

一个危险的念头在我脑中萌生：是不是可以直接在线上调整试试呢？

我当然知道规范的操作流程是“申请、评审、测试、上线”。但我内心那个骄傲的声音在说：“这么简单的参数调整，有理论依据，有‘高手’背书，还需要那么麻烦吗？小题大做！直接改了，用效果说话！”

最终，盲目的自信战胜了专业的谨慎。在一个看似平平无奇的下午，我打开命令行终端，用DBA的最高权限，敲下了那行现在想来都让我后怕的命令：

ALTERSYSTEM SETCOMMIT_WRITE ='BATCH,NOWAIT';

回车。System altered.

系统平稳如初，我嘴角露出一丝得意的微笑。

4.午夜凶铃，大祸来临

平静，是风暴来临前最可怕的伪装。

当天晚上，我睡得格外香甜，梦里甚至还在构思着第二天如何在周会上展示我的这次“神级优化”。

然而，凌晨2点15分，一阵尖锐刺耳的手机铃声划破了夜的寂静。我被惊醒，睡眼惺忪地摸过手机，屏幕上闪烁着运维部负责人老张的名字。

我的心里“咯噔”一下，一种不祥的预感瞬间涌上心头。这个时间点的电话，绝无好事。

我强作镇定地接起电话，用尽量平稳的声音问：“喂，张哥，怎么了？”

电话那头传来的，是老张压抑着怒火但又极度焦急的声音：“出大事了！XXX业务系统的数据好像……好像不对了！”

“不对了”三个字，像三根冰锥，瞬间扎进我的心脏，我的睡意荡然无存，一股巨大的寒意从脊椎直窜后脑勺。“什么……什么情况？”我的声音已经开始颤抖。

“我们半夜对账的程序报了警！今天入库的好几笔关键业务的金额，和前端流水对不上！而且……而且有几笔交易，前端显示成功了，但数据库里根本就没找到！你今天是不是对数据库动了什么手脚？！”

最后那个质问，像一道闪电劈开了我的大脑。我的世界瞬间一片空白，冷汗“唰”地一下湿透了后背。我猛地想起了下午那个ALTER SYSTEM命令，想起了NOWAIT（异步）这个词……

异步提交，在系统高负载或异常关闭时，是有可能丢失最后一部分已提交的事务的！这在官方文档的警告里写得清清楚楚，但我却在自信的驱使下，选择性地忽略了它！

我捅了个天大的篓子。对于数据库来说，性能问题是“病”，而数据不一致、数据丢失，那是“命”！我这个“系统医生”，居然亲手给自己的病人喂下了一剂“毒药”。

我的手脚冰凉，嘴唇发干，一句话也说不出来。电话那头，老张的催促声还在继续：“喂？喂！你说话啊！”

而我，只能听到自己擂鼓般的心跳声，和那个在脑海中无限回响的声音：“完蛋了...”

未完待续…

往期回顾

大白话人工智能 「链接」

数据库拍案惊奇 「链接」

世事洞明皆学问 「链接」