【浅谈DBA职业生涯---误操作篇】

【上一篇】

The Begin点点关注，收藏不迷路

【下一篇】

【 话题引入：请列举你在从事 DBA 生涯中,最难以忘怀的一次误操作】

该话题覆盖各行各业，是一个普遍存在的问题，误操作可能导致数据丢失、系统异常、安全问题等不良后果，给个人和企业带来了不必要的损失和风险。 
 
所以作为一个 DBA，或者哪怕仅仅是和数据库打交道的技术人员，要时刻保持 严谨、冷静、慎之又慎、严格执行的态度。切忌浮躁、想当然、主观臆断。

• 下面是itpub技术论坛中大佬们的经验分享。

这些案例很有趣，展现了许多因一时疏忽、不够严谨所犯下的错误。下面摘录了一些与误操作相关的案例，我们应该引以为戒，共同警醒，避免重蹈覆辙。

【案例1----记一次恢复误操作删除了生产服务器数据】

⛳ 安排一个MM在一台生产服务器上安装 Oracle，遂边研究边安装，感觉装的不对，准备卸载重新安装。
从网上找到卸载方法，其中要执行一行命令删除 Oracle 的安装目录，命令如下：
如果 ORACLE_BASE 这个变量没有赋值，那命令就变成了：
rm -rf /*，就这样，把整个盘的文件全部删除了，包括应用 Tomcat、MySQL 数据库 and so on…
 
感受：这个周末算是报销了，不挨批，通报，罚款，开除就不错了，还过什么周末啊。
 
反思&总结：本次安排 MM 进行服务器维护时没有提前对她进行说明厉害情况，自己也未重视，管理混乱，流程混乱。**

【案例2----昨天晚上一哥们儿，把数据库给整挂了！】

⛳ 接到电话7点多了，说是数据库无法访问，吓坏我了，通常这个比较棘手的。问了具体情况，才这么说，是load了几张表后，数据库暂挂了，我终于舒了一口气！

【案例3----rm 丢魂记】

⛳ 删除日志时，输入rm * .log，因为星号与log之间有空格，所以删除了该目录下所有的文件，吓得我出了一身汗
 
⛳ 一不小心用rm -rf /home目录下的所有文件,/home目录下放的账务系统的app。一看删除的路径的不对，已经来不及了。
 
⛳ rm -rf /opt/ora92/ 在测试库中本来想删除数据库，结果错误的把ORACLE软件删除了．
 
⛳ 在linux平台上，一次不小心操作，把oradata下所有的东西全删除了。
⛳ 执行 rm -rf /test 时，敲完 / ，不小心就碰到了回车……人生最痛快的事莫过于此…….

【案例4----DBA误操作 ODU救命记】

⛳ 仍然是多事9月5日上午，4号晚上睡的太晚，5号一来继续看那个DL580 G3 + Oracle 10.2.0.1裸奔机，发现一个索引应该没太大用处，Toad下DESC 这个表调出了Table，原本想删掉那个无用索引，结果点了Toad中最右边Truncate的按钮，Index没删掉，表却被截断了。
 
反思&总结：DBA对DDL操作一定要小心，Double Check后再做。个人也要休息好，不能太累。脑子不清楚时一定要小心再小心。

【案例5----记录一次惊心动魄的误操作(Oracle)】

⛳ 多扩容的5块磁盘，居然是归档所使用的/arch 文件系统盘，DG备库的归档并没有存储在ASM存储中，而是使用的本地文件系统，最终导致归档数据和+DATA磁盘组数据重复写入，数据大面积损坏，数据库宕机。
 
反思&总结：虽然此次误操作发生在DG备库，没有对生产系统造成任何影响，但由于主库是一套非常核心的数据库，如果此次事件发生在主库而不是备库，后果会非常严重。
 
出现此次事故根本原因是对备库操作不够重视，从而导致关键性操作粗心大意。根据墨菲定律，凡事如果有出错的可能，在将来的某一天一定会出错。所以要做出改变，改变心态，改变安全意识，改操作规范等。

【案例6----职业生涯中，最难以忘怀的误操作】

⛳ 一次工程实施，一个超市开业，经过一个多月的数据初始化，好不容易把所有商品都弄好了，离开门只有5分钟了，超市门口庆典已经开始了，聚集了很多顾客等着开门呢，我突然接到他们超市的人说有一个商品的价格弄错了，要我手工修改数据库改过来，我就照做了，但是我写的update语句忘了写where条件了，执行后我发现执行的很慢，十几万条数据啊，所有的商品的价格都已一样的了，此时我足足愣了2分钟，一言不发，一身冷汗。我赶紧打电话给他们经理说能否晚开门5分钟我恢复备份数据库，他们不答应晚开门，但可以限制10分钟后才让收银台收款，我才终于将心放到肚子里了。
 
反思&总结：8年过去了，现在想起来都有些怕，万一没有数据库备份，我如何负责？我如何能负责得起啊！！！！！”

【案例7----远程重启网卡】

⛳ 有一次远程操作，本想着重新启动网卡
service network restart
但不知道脑子一热
servier network stop
结果，只能跑到机房 start了

【案例8----mysql添加用户权限（心凉哇凉的啊）】

⛳ 第一次自己管理mysql的数据库，在为一个用户添加权限的时候，误操作使用了 update user set Password=password(’*’) .后面居然忘了加条件语句。 瞬间所有的用户密码变的一样了。那时候真是“心凉哇凉的啊” ，哎 现在想想都很无语~~

【案例9----记一次Oracle数据更新】

⛳ 我是在Oracle数据库中做数据更新，对一个表做update的时候，少添加了一个where条件，结果至少有二百万条数据被误更新了。。。
幸好此前做过一个备份，否则的话哭都没地方哭去

【案例10----记多机器来回切换的误操作】

⛳ 经常在十几台机器之间来回切换,有次rm -rf ./ * 清个文件夹,结果执行完发现rm到其他机器上去了…
反思&总结：从此以后执行重要命令之前先ifconfig看下ip

【案例11----【一记难忘的误操作】当shareplex的capture queue file被删除之后】

⛳ 月黑风高，不料天有不测风云，一次痛苦而难忘的误操作就发生于此。
在生产环境的误操作尤其是DBA的梦魇。虽然最后竭尽全力，力挽狂澜，但仍心有余悸。
故事发生在为Oracle提供高级复制的软件Shareplex身上。
 
起因，Shareplex有一个一直未曾解决的Bug，在vardir目录下会产生许多capture queue files，直到将vardir撑爆。目前的workaround是找到当前使用的capture queue file，人为删掉前面所有的capture queue files。
经过，傍晚是睡意朦胧之际，警觉之心顿消，copy&paste的速度越发地熟练和不假思索，于是，悲剧地多删了最后，也就是当前的capture queue file。
结果，（此处省略几千字）Fixed。

【案例12----【一次 MySQL 误操作导致的事故，「高可用」都顶不住了！】

不是有 Keepalived 来保证高可用么，即使 MySQL 挂了，也可以通过 Keepalived 来自动重启才对。即使一台重启不起来，还有另外一台可以用的吧？
 
反思&总结：查找最近发生的日志，为啥 log 文件夹被干掉了？？有位同事之前在迁移升级的过程中，发现这个 log 数据库在老的系统是没有的，所以就清理了，这就相当于把 log 数据库干掉了，同时也会把 log 文件夹干掉了。好了，终于水落石出了！

【总结】

备份 备份 再备份，重要数据都要做好备份！公司的备份最好还要多做备份的有效性测试！！！
能不用root 尽量不用root！！！
“backup is your last line of defence” -----真理呀！话说常在河边走，哪有不湿鞋。。
不操作有时是最好的操作
失败是让人记忆深刻的，失败也是会成为一个大脑里的标记的。

【上一篇】

The End点点关注，收藏不迷路

【下一篇】