DBA生存警示：系统存储级误删除案例及防范建议

编辑手记：对于资深的老DBA们，他们在漫长的职业生涯中养成了很多稀奇古怪的守则，以在复杂多变的环境中“幸存”，这源于无数血泪的教训，我曾经在《数据安全警示录》一书收录了大量现实案例，现在整理分享给大家，共为警示。

除了数据库层面，在主机、操作系统、存储层面也有很多典型案例，如果不够谨慎，主机网络层面的误操作也可能对系统产生致命的影响。

案例分享



1.误发出系统命令

HP UNIX Oracle10.2，我用root登陆后，建立了一个新主机用户，不知不觉敲了个hostname –a，大家知道后边发生什么了吗？

是和uname -a搞混了，hostname -a直接把主机名改成-a了......

listener是监听主机名的，现在找不到主机了，连续报错，还有后台trc文件也连续报错，这个主机上共有4个实例，同时连接不上......壮观啊......很快日志占满文件系统。

查不出原因，但是发现文件系统使用得很快，就想先停库，再查原因了。结果，启动的时候都ora600了。好在是测试环境的数据库，不是正式的。真是刻骨铭心啊。

2.误切换生产存储

一次冰凉透顶的操作，去年某天下午，本来是对灾备端的盘柜做HA切换，头脑一昏，随手一按，把生产端的盘柜进行了手动HA切换，20多套数据库系统在上面跑......后果不堪设想，还好一个急智，赶快又切换回来，装作什么事没有，手一直颤抖.....过后偷偷问一些在线服务系统有没有什么异常，MM只是说有几分钟很慢，数据库没反应，过后又正常了，汗....

从此对生产环境有一种“非诚勿扰”的感觉，敬而远之。

3.存储维护危险误操作

在cx700的存储navisphere管理界面，配置一个存储。同事接过去打开了生产环境另外一个存储的IE窗口，我又接手过来，一恍惚看这个存储的配置与我打开的一样，就开始做删除storage group的操作。还好我旁边另外一个同事看主机名不对，制止了我继续删除（我当时对他讲解了一下配置存储的步骤然后开始操作）。 删除了lun就丢生产环境的CRM数据了。 这个事情很可怕，那天人状态不怎么好。以后做事情越是知道状态不好，越要加倍谨慎。还有以前删除文件用相对路径来删除，../path 方式，误删除了测试环境的oracle程序，以后都用绝对路径了。

4.误删除操作系统文件

一次在IBM p570上安装RAC，由于客户网络有问题，结果失败，在删除RAC时rm -inittab*.crsd等几个RAC的启动文件，一不留神把AIX的一个文件删了，结果系统起不来了。后来多亏IBM的工程师恢复了系统。结果晚上3点才收工。

5.误操作执行系统命令

生产环境增加节点，熬了两天两夜，同事在生产机上执行了pvid=yes 导致数据丢失，最后奋战两天重新安装RAC。

防范建议

1.超级用户和数据库用户严格分离

在生产环境中，不应该给DBA以root权限，以防止不到操作给整个系统带来的影响，即便DBA可能也很了解系统，但是专业分工要求有系统管理员去执行系统层面的维护工作。

避免因为DBA的操作不当导致的系统故障。

2.事关存储无小事

存储最终容纳着用户的所有数据，所以针对存储的任何操作都不能草率，当增减硬盘，格式化分区时，都要严格进行磁盘确认、分区比较，避免因为误操作而“釜底抽薪”。

3.电源即Power

电源也就是Power，是所有动力的来源，所以当中断电源时，系统的所有环境都可能遭受影响。在处理面对电源问题时，应当慎之又慎，因为断电而导致数据库无法启动的案例比比皆是。不要让数据库因为电源问题而崩溃。