社区有很多兄弟分享惨痛宕机案例，提醒大家需警惕，以下介绍几起。

（以下案例来自社区会员分享，由社区专家孙伟光编辑整理）

01

Oracle系统参数过小导致数据库宕机

数据库双机安装完成后，数据库实例能够正常启动，但当启动全部应用软件后约10分钟，主机数据库出现自动切换至备机，再运行约10分钟备机数据库自动宕机。

原因分析：

启动应用软件前，数据库双机运行正常且能正常切换。当启动全部应用软件后，数据库发生异常切换。查看双机状态发现，网卡、磁盘等资源均正常，数据库应用资源状态异常。从上述情况初步分析为数据库问题导致双机异常。进一步分析/var/adm/message日志消息，发现引起数据库异常的原因为会话数达到最大值，新的应用连接无法获取会话资源，导致数据库管理软件判断运行系统异常后自动停止数据库。

处理过程：

1、使用sys用户以sysdba权限登陆数据库

sqlplus ‘/as sysdba’

2、查看数据库当前最大进程数

show parameter processes;

NAME TYPE VALUE

aq_tm_processes integer 1

db_writer_processes integer 1

job_queue_processes integer 10

log_archive_max_processes integer 1

processes integer 150

其中processes＝150为oracle数据库安装后的默认值

3、根据实际情况修改数据库最大进程数

alter system set processes=800 scopo=spfile;

oracle的最大会话数与系统参数processes有关，其关系为sessions＝1.1×processes＋5。根据实际情况将processes参数修改为800。

4、重启oracle数据库，再使用show parameter processes检查参数修改情况。

由社区会员“hp_hp”分享

02

P720异常宕机故障一例

主机：P720 8202-E4B

现象：

运行正常的某一天，在未出现任何告警的情况下，系统突然访问不了。机房发现主机已经宕机。现场尝试开机，无法正常开机。出现报错。故障灯亮起。

登陆AMM，出现P1-C12、P1-C14、P1 ......，包括CPU，TPMD Card，System Backplane，Firmware等等报错信息。

处理过程：

首先判断可能是CPU故障，关机后，对调CPU位置，将AMM内日志留存后清除，慢启。机子正常启动，无报错信息。但是机子风扇声音异常，与其他正常机子不同，声音异常响，但是系统未出现报错，且可以正常运行。于是未进一步排查。恢复业务。

但是在正常运行了一段时间后，一天机子有突然宕机，毫无预兆，没有一点点防备。这次现象和之前基本相似，只是这次两个CPU都报错，主板报错也再次出现，当然Firmware和新的CPU VRM稳压模块也报错。初步判断，这么多的关键部位同时不可用，还是非常少见的。况且主板若是报错了，那是很严重的。于是，先主要关注了Firmware的报错信息，并且开始怀疑是否是由于微码问题导致的异常宕机，并且导致主板CPU等关键部位报错。于是，决定先进行微码升级，再进一步排查问题。

结果：

微码升级完成后，将AMM报错保留，清除，告警灯手动关闭。AMM中，慢启。成功开机！并且没有报错，系统正常运行！异常的风扇声音也完成消除。由于担心一次重启不够，又进行了几次重启测试。一切正常。CPU主板 VRM报错均消失。不需要进行硬件更换。现在系统稳定运行。

由社区会员“ACDante”分享

03

vmware由于自动迁移引起的虚机宕机

之前虚拟环境出过一次问题，vmware自带的HA功能开启，不知什么情况虚拟机自动发生了主机迁移，但迁移进程僵死，相应那台虚机直接无法连接，最后只能连到esxi中把相应进程删掉才得以恢复。

话说本人对HA功能印象一直不好，不管是小型机还是vmware，宁可自己手动操作，也不想被HA功能影响到。

编者按：HA对于一些复杂情况很难进行有效的处理，最终还是要靠人去判断和处理，但是人不可能时刻去盯着，所以某些场景下还是需要HA软件来处理，配合监控软件，当出现定义的事件，人需要立刻去解决处理HA无法完成的事件。

由社区会员“iceman1006”分享

04

570更换电源导致宕机

现象：

用户一台IBM 570 带扩展柜，主机PS2电源坏，在线更换电源时，主机直接宕机。

处理过程：

查询IBM手册，发现如果9117-570，9116-561主机PCI槽位，P1-C6/C7有下列卡，需要停机更换电源。

(1)FC1800 - HSL-2 Ports - 2 Copper RIO/HSL card (copper)

FC1800 对应FRU 39J0792和97P6219

(2)FC1801 - HSL-2 Ports - 2 Optical RIO/HSL card (optical)

FC1801 对应FRU 39J4894和97P6878

(3) FC1810 - GX Dual-port 4x HCA GX dual-port 4x host channel adapter card

FC1810对应FRU 42R5833和39J2069

经验分享：

正确更换步骤如下：

- 1.主机PS2电源坏，检查系统确认PCI P1-C6/C7槽位是否有以上卡；

- 2.确认PS1电源状态，检查系统日志，主机各个告警灯，确认在无新的报错；

- 3.如果主机P1-C6/C7槽位有以上卡，shutdown主机进行更换；

- 4.如果主机P1-C6/C7槽位没有以上卡，可以在线更换。

由社区会员“hp_hp”分享

05

显卡引起的宕机案件

IBM X3850/DELL R720两台服务器皆由显卡引起的宕机案件。

DELL R720正常运行突发宕机问题，液晶面板显示PCI1320 BUS fatal error on system.收集日志查看指向显卡，重启服务器过程漫长，升级BIOS_CR1RR_WN32_2.5.4.EXE后正常，结案。

X3850安装一块显卡，安装后启动正常无报错，链接显示器后一切正常，一天后服务器宕机。检查日志指向显卡，更换同型号显卡出现同样的问题，一天后宕机。。。 拔下此显卡后服务器正常一个月未出现宕机问题。由于没有主板备件，未更换，未结案。

编者按：多半是兼容性问题导致的

由社区会员“张彬”分享

06

EMC DMX存储宕机事件

事件起因：

由于不是客户的核心应用，是备份系统，当管理系统发现此存储丢失了才知道存储不能访问；

当工程师到达现场之后，发现存储电池坏了3个，电源坏了一个，磁盘坏了19块，最后造成数据丢失，raid组重新划分。

工程师更换了所有备件之后问题解决，此设备没有安排专人维护是造成宕机直接原因，而且还对相关的责任人取消年终奖励，对底层技术人员罚扣工资一个月。

由社区会员“shizhe1030”分享

07

一次意外宕机后的“意外”

现场环境：

手机银行系统两台P6 550 PowerHA环境，某晚运维发现告警，一台主机意外宕机了 .接到电话赶到现场，发现P6前面板已经亮起了刺眼的黄灯，为了保护现场，先不动，先看看另外一台主机哪里能不能找到宕机线索.

1、errpt 相关报错

Deion

Possible malfunction on local adapter

Probable Causes

Local adapter mal-functioned

Local adapter lost connection to network

Local adapter mis-configured

Failure Causes

Local adapter mal-functioned

Local adapter lost connection to network

Local adapter mis-configured

RecommendedActions

Verify adapterconfiguration

Verify networkconnectivity

2 、Powerha报错日志

May 14 23:38:15 SJbank1user:notice HACMP for AIX: EVENT START: node_down SJbank2

May 14 23:38:15 SJbank1user:notice HACMP for AIX: EVENT COMPLETED: node_down SJbank2 0

May 14 23:38:15 SJbank1user:notice HACMP for AIX: EVENT START: node_down_complete SJbank2

May 14 23:38:15 SJbank1user:notice HACMP for AIX: EVENT COMPLETED: node_down_complete SJbank2 0

May 14 23:38:34 SJbank1daemon:notice topsvcs[181226]: (Recorded using libct_ffdc.a cv 2):::Error ID:6zV5DL.myHL9/i0x/6LF.4....................:::Reference ID: :::Template ID:173c787f:::Details File: :::Location:rsct,nim_control.C,1.39.1.18,4303 :::TS_LOC_DOWN_ST Possible malfunction on local adapter Adapterinterface name tty0 Adapter offset 2 Adapter IP address 255.255.0.0

May 14 23:38:36 SJbank1user:notice HACMP for AIX: EVENT START: network_down minus 1 net_rs232_01

May 14 23:38:36 SJbank1user:notice HACMP for AIX: EVENT COMPLETED: network_down minus 1 net_rs232_01 0

May 14 23:38:36 SJbank1user:notice HACMP for AIX: EVENT START: network_down_complete minus 1net_rs232_01

May 14 23:38:36 SJbank1user:notice HACMP for AIX: EVENT COMPLETED: network_down_complete minus 1net_rs232_01 0

通过如上的一些日志，基本锁定了元凶

就是因为PowerHA当时的串口心跳异常导致一台主机宕机发生。

找到了原因，那就把主机启动起来吧，结果意外发生了，这台主机无法启动了,最终定格在了11002630了。似乎是硬件问题了，赶紧call来原厂商处理。

厂商说这是因为CPU Regulator导致的，调来了备件更换完成，主机顺利启动。

由社区会员“hp_hp”分享

08

光纤通道卡故障引发的系统宕机

某金融行业客户，业务系统采用P550小机双机HA+共享存储模式，一天业务高峰期准备切换窗口，业务报怎么也切换不过去，业务无法进行。运维接报后赶紧上P550去看，errpt查看错误日志，报其中一台光纤通道卡硬件故障，造成无法连接共享存储，马上上HACMP，准备先把资源切换到另一台服务器上去，这时候怪事出现了，无论怎么操作，资源就是切换不过去。这时候时间已经过去20分钟了，领导们听说这个事都赶过来了，围在周围商讨如何解决，同时急电IBM厂家技术支持立即赶往现场救火。

在等待厂家技术支持的时间里，我们一面重新想办法切换，一边查阅系统建设时的设计方案跟拓扑图，检查是不是当时建设方案有什么纰漏，仔细排查系统问题，厂家技术支持到达后也跟着一起检查设计方案，细细检查了设计方案拓扑，终于发现问题：当初建设方案小机光纤通道卡存在单点故障，造成该卡故障以后依然占用资源未释放，热备机无法接管，以致业务系统宕机，无法处理业务请求。

找出问题后，商定处理办法，重启光纤卡故障那台小机，释放占用资源，切换到另一台P550，重新接管资源，起应用系统，恢复业务处理，万幸的是业务终于可以运行了。看看时间，这时间已经过去一个小时了，相关外联单位的打来的电话已经打爆了，耽误了业务系统的处理，大家都走不了，万幸业务最终处理完了。后面在一个月食之夜对该业务系统进行升级变更，最终彻底解决了这个问题。

由社区会员“guangshi007”分享

09

某系统EMC VMAXe存储引擎故障引起宕机

此系统是客户的核心应用，当我们到达事故现场发现存储器引擎报错，因为之前有准备，就立即更换了故障件，但第一次更换失败，紧接着又报了很多SIB卡 内存 ，电池，电源等报错，通过二线分析日志之后，又重新更换了一个引擎并把该引擎牵涉到的附件全部更换，最好问题解决。

原因：

根据客户描述电源有过不稳定的情况发生，因为楼下机房在改造其中的一个电路；

工程师第一次更换控制器失败是因为这个存储的型号只要引擎报错，管理该引擎所有的配件必须一起更换。

由社区会员“shizhe1030”分享

10

DS5020硬盘扩容导致的宕机

ds5020磁盘阵列柜，原来插了300G硬盘6块。由于业务需要。申请了6块600G的硬盘进行扩容，在线插进硬盘，建RAID,分区。一切都正常，分配给系统后也全都正常，当时以为没有问题了。但是在这两星期之后，由于机房电力改造，对机房所有设备下电进行维护，一切恢复后启动DS5020.却没有启动。加电后控制器在多次重启之后锁定，导致整个虚拟机系统无法启动，百思不得其解。

后来通过命令行连接控制器。对控制器进行解锁后开始尝试各种可能性，结果如下。

拔掉了后添加的600G硬盘后启动正常。插入600G硬盘则会导致盘阵启动锁死，后来删除600G硬盘的RAID。然后关机。插入硬盘，开机，建立RAID。分配。之后恢复正常。应该是由于在线扩容时出现了问题导致重启后控制器无法识别。关机，扩容之后就一切恢复正常。

由社区会员“pysx0503”分享

11

AIX cfgmgr扫描新磁盘，哐当一下，业务系统宕机

某金融用户报表业务系统,IBM P750*2 HDS VSP PowerHA环境，由于批处理IO时间较长，用户新购置了一台HDS闪存阵列解决目前存储性能瓶颈问题，新存储加电上架规划配置一番后，用户识别新存储准备数据迁移等一系列的工作，就在cfgmgr扫盘时候，没反应了，发现IBM P750分区宕掉了。收集日志厂商一轮分析过后。发现一个细节被大家忽略了，导致今天的后果。

由于当初用户使用的VSP 存储HDLM版本较老，不兼容新采购的HDS闪存。 导致了此次事件的发生。

由社区会员孙伟光分享

12

客户P520小机宕机，这锅我不背

当年，本人还是一个集成仔，风里来雨里去给客户送糖送水。一天P520服务器电源需要跟换，手下小弟没来，我就亲自上了，好久没自己上了，态度还是蛮重视。我刚换完，问下客户DBA好了没有，小D很高兴的跟我说OK。谁知没过几分钟，机器谈了。。。悲剧，小D跟我说：兄弟大意了吧！我当时也懵逼了，可是一想这锅一背，客户这混不下去是小，面子丢大发了。找原因，先把备机起来了，不影响人家使用，然后详细找原因。

大致过程：

1、查系统各种日志，看看是否有异常？有异常是什么方面的异常？软件 or 硬件？

2、通过nmon分析当时系统是个什么状态，发生了些什么；

3、查审计，当时谁都在连在这儿，干了些什么；

4、查oracle数据库，当时你干了啥，有人强迫你吗

5、收集证据，接近真相

原因：

不是换电源的问题，是换了电源后，一开发哥们把一不完善的脚本执行了，结果是造成内存很CPU狂飙，最终系统撂挑子不干了，倒霉的我差点背锅。

最终，客户说兄弟不错啊，可还是我请客户那边屌丝兄弟吃的饭！

教训：

守规矩，平时多一点保护自己意识和行动，干事全面细致一点，懂的多方能从容，关键自己要对自己有信心，遇事沉着冷静！

由社区会员“mmsc5166”分享

13

比down更可怕是人为的误删除

都说知人知面不知心，比down更可怕是人为的误删除，在没有数据库审计和灾备的情况下怎样快速恢复被损坏的数据就显得尤其重要。下面是昨天在客户现场发生的真实的case。

13:50 receive C site MES admin call about this issue.

13:55 login C site sqlserver database server (active/standby) and check sqlserver log to check if it was some error information.(no error information)

14:00 check TT.XXX in standby database if standby database corresponding read only table value would be changed or not. (already change)

14:00 ~ 14:15 check table TT.XXX, if it is an partition table and how many datafiles the table occupied and check those datafiles locations.

14:20 call C SITE MES admin to confirm the time period which is necessary for restore and recover database XXX.

14:30 check the database backup files posititon

14:40 copy backup files from active server to standby server in order to prevent crash current using database.

14:50 login on C site standby database server and find that backup files

15:00 modify restore and recovery in order to restore an different named database (C_TEST) at different location (F:TEST)

15:20 restore process failed at first time dure to restore error

15:30~15:50 restore process successed at seocnd time

15:50 make link server at database XXX in active database server to C_TEST in standby database server

15:51 call C site MES test and confirm that is OK

那么兄弟们可以看到 sqlserver相比Oracle还是差了一些。sqlserver把undo 和 redo统一集成在transaction啦，那么从2006之后可以看到sqlserver可以直接备份和还原 filegroup 那么也就是说 sqlserver数据库可以只还原一部分数据库不需要全库恢复。

那么如果熟悉数据库的架构的情况下可以利用现有的条件加快恢复速度。

我这的sqlserver使用的always on结果，这玩意类似 oracle的DG，那么为啥不用只读的standby恢复数据呢？

由于always on sync commit以及 极低的延时设置使得这一想法无法实施，不过如有不止一个slave那么可以考虑真的可以 这么设置 。

编者按：车开的再好，难免被别人撞。系统维护的在完善，也有不守规矩的人乱搞。

由社区会员“liulei_oracle”分享