共计 2308 个字符,预计需要花费 6 分钟才能阅读完成。
导读 | 对于资深的老 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 数据安全警示录》。
![post-qrcode](https://www.xgss.net/wp-content/uploads/2023/07/二维码-微信公众号256x256.jpg)