昨天阿里云在运维上出现了严重的事故，引发文件删除，让我想起这篇文章，补充再发出来。总有很多情形，你无法想象，数据库的故障遭遇也是如此。
如果没有完善的流程、规范，并且进行规范化的审核，那么什么故障都可能发生，人、流程和工具，必须要互相匹配，完美结合才能发挥最佳效应，而运维就是要疯狂躲避各种坑。
分享几则我们遇到过的客户恢复故障，与大家共为警醒，注意这些都是真实的案例：
-
服务器找不到了
某次客户找我们恢复数据库，说某个数据库出现故障，原本以为不再需要了，现在还需要其中的数据，可能是时间太久远了，工程师到现场后，客户说服务器找不到了，就算了。
三个月后，客户来电说，服务器找到了，我们又去帮用户恢复了数据。
-
服务器搬走了
某次客户数据库故障，检查发现，是RAC的某个节点服务器被搬走了，以为不用了，郁闷的是，断电还导致了ASM磁盘头损坏，还好11g修复ASM磁盘头很简单，迅速帮助用户恢复了数据库运行，再搬回服务器，加入节点。
-
磁盘搬走了
也是今年的某个客户，新上线服务器，客户找了一块以为不用的磁盘，强制拉过来格式化，发现另外一个业务库应声倒下了。
-
DBA走了
最近提到过的一个客户，因为把DBA解雇掉了，结果，DBA偷偷上来把整个库给删除掉了，业务挂了很久很久。
-
网线拔了
这是2015的案例，在业务高峰，新上一个交换机，网络运维把生产数据库的网线拔了，影响业务10分钟。这是金融业务，据说客户的人都跑到机房，机房满员。
-
磁盘故障
这也是2015年的新案例，客户的存储工程师划分给数据库ASM的磁盘小于请求容量，数据库文件扩展时越界产生了故障。这是队友埋的坑。
同志们，Oracle是坚强的，但是数据安全是脆弱的，警惕随时可能发生的故障，不断强化数据安全，加强运维规范化，如何都不为过。
本文出自数据和云公众号，原文链接
