吵吵   2015-05-27  阅读:1,001

办公室里,人群嘈杂,烟雾缭绕,作为一名伟大的程序猿的我还在拼命的在处理一个bug.

有人叫:“吵吵,你帮我看下这个”

我直接无视,

她继续叫:“不理我,你帮我看看这个网购的账号为什么绑定不了么!”

我相当之不耐烦,匆忙写完一条SQL语句,然后点击“提交”,正是我准备回身去搭理她的那一霎那,窗口被修改的记录达三千多条,直接将我带入脑袋一片空白的境地。

DBA绝对是个细心的活,再重要的事情,也不要去打扰正在干活的DBA!

过了足足十秒钟,我才从空白中回复过来,暗自惊喜,好在更新的一张使用频率不高,记录也相对较少的表,否则,若是更新了张主表,那后果,我擦了把汗,绝对无法想象!

事务、日志、疯狂的百度,我都没有找到一个解决的办法!

眼看下班在即,我只得放下手头的工作,该死的饭堂再过会儿,就毛都没得吃了。

匆匆忙忙吃了两口饭,边吃还在边想,怎么办呢?不会让我手工一条条的记录去补吧,三千多条呢,逗我玩呢?

咦?手工去补?我干嘛要去补啊,写个程序自己去修改不就行了么?

我扔下盘子,冲回机房,把昨天的备份恢复到一台备用机上,然后写个代码,从备用机的数据库中取出数据,然后再根据主键写回到现在的数据库中去。

写成功的数据一条条的在提示框中滚动,当最后一条写完停止住的时候,我终于长长的舒了口气,从机房拿出我的折叠床,展开在办公室睡起午觉来,感觉,睡的真香。

为了避免像这次这么吓破胆,总结一下:

1、在delete update之前,一定要select一下,确保符合条件的记录数是对的。

2、千万不要嫌麻烦,加个事务BeginTrasaction,万一不对呢,还可以rollback.

3、做好备份,准备好备用机,实在不行的时候,赶快切,也比宕机或者丢掉大部分数据要强。

DT时代,数据就是宝贝,贼贵!

吵吵微信朋友圈,请付款实名加入:

吵吵 吵吵

发表评论

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