在新年到来之际，我们除了要恭祝大家新年快乐之外，还要警示大家，加强管理，防范问题，本文精选了过去我们看到、遇到、分享的一些案例，在轻松而愉悦的学习之后，别忘了低头看一看自己的系统。

我们都知道，很多客户和企业经常选择在节假日进行数据库或系统维护，而工程师也很容易在假期前后产生“假期松懈症”，所以通常假期附近总是企业运维事故多发期，而如果节假日又赶上了月初月末，则问题发生的概率就更高了。墨菲定律无处不在，不要以为那些小概率事件不会发生，它们只是在积蓄力量。

在生产实践中，如果没有完善的流程、规范，并且进行规范化的审核，那么什么故障都可能发生，人、流程和工具，必须要互相匹配，完美结合才能发挥最佳效应，而运维就是要疯狂躲避各种坑，并不断通过产品去完善和改变工程师的世界。

故事一：戏剧性的转折

多年前这个案例让我记忆犹新，这个故事告诉我们无论何时，做事都要谨慎用心，一时马虎将是行业传说：

最惨的一次（经历）是和公司的一个哥们一起出差,那个哥们不知道出于什么考虑,将主服务器和备份服务器的IP反了一下,但是tnsnames没做修改,我准备重做备服的时候,使用了drop user cascade,把所有的用户都干了一遍。

刚刚干完,所有科室上夜班的护士小妹妹都给我打电话,说科室里的电脑全部不能用了,当时急的不行了,还好习惯还不错,来的前一天做了一个全库冷备，立刻进行了恢复,不过也丢失了一整天的数据。

一个小时以后，所有的院领导以及信息科的工作人员都出现在我的面前，并质问我原因,我只能一脸无奈的告诉他们刚刚来了只熊猫，那只熊猫烧了把香,然后数据就全丢了。

然后给了他们一个卖瑞星的兄弟的电话,那个兄弟连夜驱车200公里赶到目的地,到场以后首先确实了一下那个烧香的熊猫的存在,然后指出了那只熊猫的巨大危害性，最后建议他们购买一套全院级的杀毒软件。

大院长听取汇报后当即指示，立刻购买一套全院级的杀毒软件，第二天一早就在购买合同上签字盖章。

这个事情造成四个后果,

第一,我在所有删除性操作以前都要核实一下对象的准确性,

第二,我从此拒绝和那个哥们一起出差，

第三,那个卖杀毒软件的兄弟会经常联系我，看看我有没有犯类似的错误。

第四,兄弟越多越好

富有戏剧性效果的案例，说出一个心酸的真实故事，但愿我们都不要通过跌倒去收获经验，而是通过严谨去防止错误吧。

故事二：一个空格引发的血案

系统运维从来就是一个精细化的工作，除了规则与规范的约束之外，运维人员的严谨、谨慎也必不可少，有时候一个简单的错误就会导致一场灾难，小到一个字符，一个空格。本文的案例就是因为一个空格导致的，Oracle RAC遭遇故障重启。

故障现象：客户10.2.0.4 RAC for Solaris 10环境突然出现了实例重启。

故障过程：数据库正常运行到下午3点左右，随后两个节点分别重启，其中一个节点上的实例无法自动启动。检查两个实例的告警日志发现，在节点重启前，两个节点都出现了明显的ORA-27504错误。

错误信息：

ORA-27504: IPC error creating OSD context

ORA-27300: OS system dependent operation:

requested interface 192.168.168.3 NOT found.

CHECK output FROM ifconfig command

注意，这里的错误信息提示已经比较明确，请求的IP地址不存在，需要检查ifconfig的输出。接下来就是IPC超时：

Wed Apr 10 15:08:16 2013

IPC Send timeout detected.Sender: ospid 25748

Receiver: inst 2 binc 430164 ospid 11890

再然后实例驱逐不可避免：

Wed Apr 10 15:16:40 2013

Waiting FOR instances TO leave: 2

导致问题的原因根据错误信息很容易分析出来，节点2上的IP地址被修改，导致心跳通信出现了异常，而节点1试图将节点2踢出集群，但是由于无法和节点2之间进行通信，因此只有等待节点2重启。

检查节点2的操作系统日志,获得如下主要信息：

Apr 10 15:00:04 ip: [ID 482227 kern.notice] ip_arp_done: init failed

Had[4135]: [ID 702911 daemon.notice] VCS CRITICAL  

CPU usage ON bj-sst IS 92%

sshd[13485]:error: Failed TO allocate internet-DOMAIN X11 display socket.

在15点04秒时出现的ip_arp_done: init failed信息，说明设置网卡接口时使用了主机名信息，且主机的IP地址被在线修改。

最后根据HISTORY确认，发现有人通过root登录系统：

执行ifconfig –a6来检查IPV6的地址，但是命令敲错

执行了ifconfig –a 6，在a和6之间多了一个空格

导致主机所有的IP地址被设置成0.0.0.0

于是导致了上面的整个故障，一个空格导致整个集群瞬间崩溃，这就是一个空格引发的血案。

这个案例给我们的教训是，对于特权用户，任何一个操作，具体到命令级别，也需要小心谨慎，DBA用户和ROOT用户都在此列。

故事三：那些运维中的匆匆乱

分享几则我们遇到过的客户恢复故障，与大家共为警醒，注意这些都是真实的案例，种种小疏忽，导致大事件：

服务器找不到了

某次客户找我们恢复数据库，说某个数据库出现故障，原本以为不再需要了，现在还需要其中的数据，可能是时间太久远了，工程师到现场后，客户说服务器找不到了，就算了。

三个月后，客户来电说，服务器找到了，我们又去帮用户恢复了数据。

1.服务器搬走了

某次客户数据库故障，检查发现，是RAC的某个节点服务器被搬走了，以为不用了，郁闷的是，断电还导致了ASM磁盘头损坏，还好11g修复ASM磁盘头很简单，迅速帮助用户恢复了数据库运行，再搬回服务器，加入节点。

2.磁盘搬走了

也是今年的某个客户，新上线服务器，客户找了一块以为不用的磁盘，强制拉过来格式化，发现另外一个业务库应声倒下了。

3.DBA走了

最近提到过的一个客户，因为把DBA解雇掉了，结果，DBA偷偷上来把整个库给删除掉了，业务挂了很久很久。

4.网线拔了

这是2015的案例，在业务高峰，新上一个交换机，网络运维把生产数据库的网线拔了，影响业务10分钟。这是金融业务，据说客户的人都跑到机房，机房满员。

5.磁盘故障

这也是2015年的新案例，客户的存储工程师划分给数据库ASM的磁盘小于请求容量，数据库文件扩展时越界产生了故障，金融客户的大事故，这是队友埋的坑。

Oracle数据库是非常坚强的，但是这个坚强是构建在稳定的基础架构之上的，运行基础决定上层建筑。数据安全是脆弱的，警惕随时可能发生的故障，不断强化数据安全，加强运维规范化，如何强调都不为过。

故事四：某年元旦数据库的种种

在某个元旦假期中，我们就收到了很多的紧急援助请求，这其中大多是熟悉的问题，包括：

1.数据库回滚段问题导致的ORA-01555错误；

2.SYSTEM表空间坏块导致的BootStrap失败，2662错误；

3.误删除导致的数据丢失；

4.空间不足导致的归档挂起；

阳光之下，并无新事，这些问题大都是我们以前曾经面对过的，然而我想重复的，DBA至关重要的一项素质是：严谨。在面对重要操作时的小心谨慎，反复确认；在可能损坏数据操作时心怀警惕，确认无误；唯有充分重视这份数据工作，才能在实践中履险如夷，达成使命。

比如误删除操作这样的事故，直至今天，在很多用户环境中仍然屡见不鲜。

上周在微信大讲堂中还有人提问：是否可以用update user$的方式更改Oracle数据中的用户名？

最近有客户遇到了一则数据库故障，起因是当进行一个数据表创建时遭遇到限制约束，Oracle的表名不能超过30个字符（12.2扩展了），这是数据库的内在限制。然后如何解决呢？应该说是数据库知识已经足够普及了，程序员们找到了数据字典表，将限制字段的长度改掉了。

大家能够评估后果么？数据字典被修改，整个数据库开始出现ORA-600错误，就此触发一次故障。

很多时候我们说，无知者无畏，当动手能力太过于强大时，也会使数据库遭遇不测。而对于企业数据库环境来说，内部的风险往往大于外部。

不以规矩，不成方圆。做任何事都要遵循一定的守则和规范。

故事五：某年中秋数据库的种种

在中秋节前，我们一共接手了3则数据恢复案例，我和大家分享一下案例概要，与大家共为警示。

1.磁盘故障导致数据库损毁

用户的磁盘组一共8块硬盘，做的RAID5，由于是制造企业，对于IT的了解和认识有限，可以一直侥幸的认为系统是足够安全的，每日进行逻辑导出备份，但是备份同样存储在一个存储设备上。忽然之间，整个RAID组中同时损坏了两块硬盘。一切数据荡然无存。

对于这种情况，只能从幸存的6块盘上进行数据扫描，抽取完好的数据，尽量以最大限度的恢复其中完好的数据内容，当然如果另外两块硬盘有任何一块还可以离线读取，那么事情就会变得简单。

无数事实给我们的警告是：备份重于一切。注意还需要是：分离存储的备份重于一切。

2.故障恢复时发现文件离线

客户通过备份去恢复和重构一个系统，恢复时发现有一个文件处于离线状态，无法Online，客户尝试了很多方式和方法，最后的结果是仍然被多个ORA-600错误所困扰，无法回复一个正常的数据库。

这也是备份时缺乏验证和检验导致的，这类问题给我们的警示是：确认备份的有效性和备份同样重要。

3.断电引起数据一致性问题

今天遇到的另外一个用户，由于断电导致了数据库无法启动，这个数据库是没有备份的，只能通过隐含参数牺牲一致性，最后启动数据库。这个数据库系统数据量不大，但是在线的应用相当重要。

这个问题给我们的警示是：再小的系统遇到灾难时也和大系统恢复同样复杂。

故事六：那些年我们遭遇到的数据回档

在行业里，数据回档是一个艰难的词汇，这意味这数据的彻底损失，为了一致性不得不放弃部分数据，在金融行业，这会是灾难。

看一看这样的案例吧：

2015年中秋节IT论坛的数据回档

ITPUB技术论坛 - 作为国内最大的数据库论坛，因为意外导致数据故障，当时全站数据回档到6月10号的数据内容，其他数据正在紧张的恢复之中。回忆起几年前，CSDN用户账户和明文密码泄露，这两者可以共为警醒。

以开发为主的论坛泄露用户明文密码，以数据为主的论坛丢失论坛数据。这不禁再次让我们警醒：如何强调备份和安全的重要性都不为过。

2017年炉石传说的数据回档

炉石因为数据损失选择了回档，已经在行业里引起了巨大的关注，我的文章详细分析了这个事故：炉石传说的Oracle故障，不要以为你也可以幸免。在这次事故之后，很多用户开始去梳理如何改善自己环境的数据安全，保障业务的连续运行。

多年以前我曾经在书中写到：唯一能够让DBA在深夜惊醒的事情就是 - 没有备份。想一想如果今晚你的硬盘损坏，数据丢失，你将如何应对明天？

所以如何强调数据备份、数据保全、数据安全都不为过，愿大家的数据库能够平平安安的度过2017年！

故事七：那些运维保平安的非理性因素

不止一位老专家和我传授过，运维保平安的不传之秘：内心平和，外保安详。

他们一般是这么执行的：

还有这样的：

海外的经验：

当然：如果假期数据库就是不肯消停，还有以下这些兄弟可以为您保价护航，可以及时 Call 云和恩墨的紧急救援团队，让数据库也过一个安心的新年！