DBA误删警示录！

硬件维护人员删除归档日志的时候，把节点2的整个ORACLE_HOME都删除了。在删除的时候没有注意到目录改变了，还键盘做了一个向上的动作，刚好就是刚刚使用的 rm -rf *，然后一个下意识的动作回车就这么按下去了。

我最难忘的：root用户在根目录下rm -rf abc *，abc和*之间有个空格，结果把OS删除了。已经成为佳话。什么事情都可能发生的。从此，整个人好像变了一样，做什么事情，都三思而后行了。

偶的教训不是很深刻，不过意义很重大：

删除一些 trace 文件，然后就直接删除rm orcl*， 结果通过VPN到生产的，网络太慢，命令刚刚慢慢的显示出来，看都没看直接按回车，结果执行的命令却是rm orcl *，因为orcl和星号中间有个空格，所以把这个目录下面所有的内容全部删除了。出了一身冷汗，试想，如过是删除数据文件目录下的内容，那立马死翘翘了到现在为止，每次都要等命令完全显示出来，从头到尾看一遍再执行。不过，大多数错误都是在很繁忙或者很疲劳的情况下发生的，呵呵，看来DBA应该多休息才是。

安装数据库的时候su – chmod 777 -R /oracle ，多输入一个空格变成chmod 777 -R / oracle ，许多系统文件属性变坏，Unix瘫痪这个错误犯了两次，用系统恢复磁带重做系统，幸好是测试机。从此以后系统部门的同事不肯给root口令。

當時，那幾天都是很疲勞的。在開發環境作數據文件分佈調整時，先cp完某個表空間所有文件到其他地方，然後作*匹配rm了此表空間在此目錄的數據文件。但是rename時發現居然有一數據文件沒cp過來，忘了說了，此表空間是system表空間。沒辦法，開發人員明天還要使用這個環境。幸虧之前有一備份，不過當時磁盤空間不是很充裕，足足折騰了一夜才搞定!想起來都後怕哦，幸虧不是正式環境了!再以後，就很少用cp，rm了，特別是rm *，一般是此類操作用mv來完成。需要rm的東西，一般mv到一臨時目錄了，再rm了！呵呵，可能都有點謹慎過頭了哦。

自己写了个rman备份以及备份成功后rm旧log的shell脚本，log的目录赋值給变量，结果执行時目录赋值沒成功，该变量指向了另一個目录，结果下面的东东全没了，系统立即报错(把用户的home目录删了)。幸好当时头脑还很清醒，也没误删什么重要的数据，很快就搞定了。以后脚本中要rm某个目录的东东再也不敢用变量表示了，直接hardcode进去算了，这样也放心。另外出问题后一定要冷静，定位出问题原因后再动。

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

刚进现在的公司不久时，做一个数据仓库项目，同事周日加了一天班把数据抽到一个大表空间里，大概 100G，第二天因为临时表空间增长很快，决定重建，这个 临时表空间的开头和那个大表空间名字是一样的，只是后面加了一个_temp，当时也是因为事情比较多，认为这是很简单的，结果输入名字就忘了输入_temp，把大表空间删除了，同事白加了一个星期天，虽然没影响什么进度(数据可以重抽)，但这次教训是深刻的。个人教训:

1.rm的时候一定不要用*之类的，要用的话要看好再用，否则会有意想不到的效果。

2.人在累的时候最容易出错误，所以每一次回车都要看好。

上面仅仅是我们摘录的一小部分误删除案例，但是这些案例带来的影响有些是深远的。如何在日常工作中避免这样的低级错误发生？有一些简单可操作的建议。

或者制定一个规范，通过mv的方式进行文件转移，通过一定时间段(如一周)观察无误后，再彻底清除数据文件rm操作的危险性必须得到技术人员的充分重视。

很多用户是在空间达到100%之后才去匆忙进行空间清理，匆忙常常会带来考虑不周，误操作等意外发生。所以我们建议加强数据环境的存储空间监控，不要等到100%再去应急，应当总是使空间留有阈量，提前 进行空间维护，避免手忙脚乱的应急处理。

如果不可避免的要进行紧急的文件删除工作，那么在条件允许的情况下，应当做好备份转移到其他主机或存储，避免无法回退恢复的灾难。通常文件的转移并不会花费太多的时间，在可能情况下用转移替代删除，在必须删除时，也要考虑能否保留最后一个备份。

人在疲劳和不清醒的状态下极易犯下错误，所以应当尽量避免在连续工作的疲惫状态下，或者在梦中惊醒的凌晨迷糊状态下进行维护工作，比如文件删除，在这种状态下，极易出现误判，造成误操作。另外，在操作之前确认你的当前路径，很多灾难是由于当前路径错误导致的，在 Unix/Linux下，可以通过pwd命令来确认。

前面提到过这点建议，再次重申，在执行重要操作时，最好有两个人同时在场，互相监督审核，避免一个人草率或者考虑不周导致的误操作。

以上内容摘录自盖国强《Oracle DBA手记4 数据安全警示录》。