作为DBA,我最无助的时刻

作为DBA,我最无助的时刻插图

和同事一起吃饭,聊起了我们以前工作中搞砸和见识过的其他人搞砸的那些事儿。

虽然如今早已不再犯那些错了,但是想起过去犯的那些错感觉好笑的同时也心有余悸,这些错让我们受益颇深。

非专业DBA脑子发热

我工作的这几年里遇到过各种“稀奇古怪”的案例,大多数都是非专业DBA脑子一热就干了。

比如:

1、误删除Oracle软件

某项目人员删除归档日志的时候,把节点2的整个ORACLE_HOME都删除了。在删除的时候没有注意到目录改变了,刚好就是刚刚使用的 rm -rf *,然后一个下意识的动作回车就这么按下去了。

2、空格导致的误删除

我最难忘的:客户系统管理员使用root用户在根目录下rm -rf abc *,abc和*之间有个空格,结果把OS删除了…。什么事情都可能发生的。

还有一例:

某客户系统管理员删除一些 trace 文件,然后就直接删除rm orcl*, 结果通过VPN到生产的,网络太慢,命令刚刚慢慢的显示出来,看都没看直接按回车,结果执行的命令却是rm orcl *,因为orcl和星号中间有个空格,所以把这个目录下面所有的内容全部删除了。出了一身冷汗,试想,如过是删除数据文件目录下的内容,那立马死翘翘了。

3、空格导致的误授权

某项目人员安装数据库的时候su – chmod 777 -R /oracle ,多输入一个空格变成chmod 777 -R / oracle ,许多系统文件属性变坏,Linux瘫痪。幸好是测试机。

4、误删除数据文件

某项目人员新接手一个项目,加了一天班把数据抽到一个大表空间里,大概 100G,第二天因为临时表空间增长很快,决定重建,这个临时表空间的开头和那个大表空间名字是一样的,只是后面加了一个_temp,当时也是因为事情比较多,认为这是很简单的,结果输入名字就忘了输入_temp,把大表空间删除了,白加了一个星期天,虽然没影响什么进度(数据可以重抽),但这次教训是深刻的。rm的时候一定不要用*之类的,要用的话要看好再用,人在累的时候最容易出错误,所以每一次回车都要看好。

5、误删除目录中挂载

一次生产环境linux系统,做整个项目目录的移植,cp一份确认正常执行后直接rm原来的目录,没想到子目录中居然有mount到其他server的XX目录,结果可想而知。

上面仅仅是我们见识过的一小部分误删除案例,接下来聊一聊自己以前犯错的经历,前车之鉴、后事之师。

我太难了

误删生产库的新闻从来没有停止发生过,我们看到类似这种有人犯了特大的、不可磨灭的错误的文章,都不免心生畏惧。

我们意识到自己并不是没可能犯那种错——大多数时候都是悬崖勒马。

我在干第一份工作的时候,有一个高级数据库管理员在上班第一天就误删了生产数据库,这种例子简直比比皆是。工作团队用三天前旧的数据库备份帮他弥补了过失,让他保住了工作。

去年年初某天,我被叫去调查一个客户生产中出现的问题。他们本来要针对某一功能进行产品测试,但是他们的前台功能突然什么都显示不出来了。我猜想可能是系统有 bug 或者有漏洞所致。

我登录进生产数据库,发现某张业务表是空的。OK,这证实了网页显示空白的情况。

用户表里面还是有用户的,这就奇怪了,所以我们丢了业务表数据,但起码他们的测试用户仍有他们的账号,我们可以解释说是这是个测试版,而且这种事情时有发生。

接下来一会儿我就犯迷糊了。我记不清楚自己干了什么,我认为自己不会蠢到在控制台窗口输入了删除表中用户的指令,可情况就是这样——现在既没有业务表,也没有用户表。

我呆坐着,感觉有点震惊。

然后我的大脑高速运转,开始想办法修复问题。

我真的删掉用户表了吗?是的。

我们运行备份数据库了吗?没有。

该怎么向客户解释呢?我不知道。

我记得自己去找了项目经理,坐在她旁边解释事情发生的经过,业务表中没有数据了,所以网站看上去是空的。哦对了,我还误删了用户表。现在他们需要重新邀请所有的用户——如果他们还能想清楚用户都有谁的话。

哎呀。

我回到自己的座位上,感觉深受挫败。

但是我觉得事情有些蹊跷,我们怎么可能一开始就弄丢了业务表呢?

于是我继续深究下去,一方面是因为难以接受这个结果,一方面是想挽回颜面。之后过了一小会儿,我注意到了关键问题。

服务器上还有另外 5 个数据库,其中一个的名字和我正在看的那个数据库的名字非常相似。

我一检查,发现业务表都在里面,用户表也完好无损。事实证明是因为配置发生变化,无意间让它变成了生产数据库,导致网站指向了全新的数据库。我在里面看到的那些用户呢?种子数据罢了。

真是如释重负!一早上神经紧绷、胃酸翻涌,搞得我浑身不适,但好在我们“修复”了所有的数据,并且找到了问题真正的症结所在,没有提前宣布误删数据库的坏消息。

这个小插曲让我们受益良多,最简单的一个就是:现在我们总是在给数据库做备份,这可能是我们运维人员最有效的后悔药。

从失败中受益

这是每次失败的经历给予我的启发。只要你愿意学习,几乎每次这样的经历都会让你从中受益。

如果人能够从错误中吸取教训,那么就会有所进步。如果一个队员是第一次犯错,我尽量不会对他表现出不满态度,他们往往已经知道自己把事情搞糟了。

但我也努力不去苛责那些总是犯错、屡教不改的人,他们也需要被同情。

对待犯错,如果你能够做到这四点,那么就会不断进步:

  • 对曾经犯过的错误可以自嘲一番
  • 从中吸取经验教训
  • 在之后努力为自己正名
  • 和他人分享,让他人也能从中获益。

关于犯错的宝贵价值,我留给你们一则名人轶事:20 世纪初期,IBM 的总裁托马斯·J·沃森遇到了一位因为多次决策错误让公司损失惨重的员工,当问及是否要开除这个员工时,沃森答道:

“不,我刚刚花了 60 万美元培训了他,我怎么会让其他人雇佣他来获得他的经历呢?”

觉得本文有用,请转发、点赞或点击“在看”

聚焦技术与人文,分享干货,共同成长

更多内容请关注“数据与人”

作为DBA,我最无助的时刻插图1

为您推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注