宕机案例分享

刺骨的言语ヽ痛彻心扉 2022-06-16 06:29 421阅读 0赞

ERP备份导致的一起宕机案例

1、现象回顾

某日凌晨，其中一台ERP数据库主机宕机。AIX.5.3 HACMP RAC数据库环境。

2、故障分析

宕机时间点是在备份期间。通过分析数据库日志、系统日志、发现导致数据库停库的主要原因是由于HACMP的一个守护进程haemd发生自动重启，由于oracle数据库和haemd进程之间有关联，因此数据库在发现haemd重新启动后也自动停止。

经IBM工程师及实验室分析，Haemd自动重新启动的原因是由于在一定期间内（参数为2分钟）没有给HACMP系统响应，其原因之一是由于系统过于繁忙，没有响应Haemd。

随后分析结果发现在备份期间，从存储看系统不是很繁忙；但ERP数据库服务器主机性能异常：有时会出现阶段性的不响应现象，同时系统I/O高。停止备份后，这种现象消失。

经IBM实验室协助，初步经过分析：

1)AIX系统内存分为计算类和非计算类内存。非计算类内存主要用于文件操作CACHE，以便提高文件再次读写的性能。目前ERP生产数据库占用了近20G内存作为文件系统CACHE。

2)当文件系统CACHE有空间时，写文件操作将不会产生阻塞，当文件系统 CACHE无空间时，系统将会根据内部策略，挤出部分CACHE。当无法找到空闲的CACHE时，会等待系统调整出空闲的CACHE。当出现大量等待时，系统可能出现无响应的状态。

3、解决方案

考虑到将来数据量的增加，如果无法解决较大I/O对系统的影响过大的问题，这个隐患将一直存在。

调整该备份文件系统的属性，在该文件系统的I/O请求到达一定值的情况下，阻塞对该文件系统的读写I/O，从而保证预留足够的资源给系统。具体参数为Maxpout、Minpout。Maxpout、Minpout参数的选择，是和具体环境相关的，没有一个统一的建议值。若该参数设置不合理，可能会影响到文件系统的读写操作。而合适的参数需要经过设置、观察来确定。

比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 script 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 script 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”分享

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”分享

P550/P570宕机案例

某周末，客户致电，说核心业务无法访问。工程师到达现场，发现客户环境（P550/P570--HACMP）P550两台小机均关机。发现客户现场有部分服务器也已处于关机掉电状态。此时客户才发现，市电周五晚上断电过，但是客户机房配备有2台UPS，机房设备一半一半分别接到2台UPS上。排查发现其中一台ＵＰＳ无法供电。而两台小机均有一路电源接到该UPS，导致市电断电后，直接宕机。

后将小机通电开机，发现P550无法开机，CPU VRM稳压模块报错，由于客户业务较为重要，将P570已经拉起来，准备将HA集群在IBM P570单节点运行。却发现HA无法将Oracle数据库拉起。由于时间紧迫，手动在P570网卡上添加IP别名后，手动挂载VG，恢复业务。

后续，将P550稳压模块进行更换后，发现仍然无法开机，又出现新的报错：11002630，再次更换CPU板后，P550小机正常开机。安排停机窗口进行排查恢复。在处理过程中，集群出现意外，在HA拉起来后，经业务测试，发现/orafile丢失一部分数据，此时备份数据最新的为前一天晚上23点，单天的数据未做备份，只能采取数据恢复，最后成功将数据恢复回来。重新配置ＨＡ，模拟故障切换，测试业务，验证数据完整性，业务恢复正常！

由社区会员“ACDante”分享

P570宕机案例分享

时间太久，记录一下流程吧。

IBM 570意外宕机，处理过程如下：

1、首先查看asmi日志，电源和风扇故障，更换了2个电源和1个风扇后，可以启动到standby模式。但是非常多的firmware报错。

2、升级微码到sf240-417后，微码报错消失。

3、激活分区失败，hmc终端会出现几秒的”ide inited failed“提示，然后消失。接着卡死，报找不到硬盘。

4、观察外观，发现后端的光纤卡灯特别弱，有时会不亮。

5、查了下570的红皮书结构图，发现ide controller(红线圈住部分)同时处理pci设备和硬盘背板设备过来的io，根据现有故障现象，判定ide controller有故障。

![640_wx_fmt_jpeg_tp_webp_wxfrom_5_wx_lazy_1][]

6、通过ibm system information center，定位到ide controller的location code 为p1-15，不是一个可替换的FRU，必须随同IO backbone（就是主板）一起更换。

7、更换io backbone后，系统正常启动，进入系统微调后，一切正常。

由社区专家“王巧雷”分享

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”分享

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

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

1、errpt 相关报错

Description

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”分享

显卡引起的宕机案件

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

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

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

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

由社区会员“张彬”分享

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

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

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

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

由社区会员“iceman1006”分享

570更换电源导致宕机

1、现象

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

2、处理过程

查询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

3、经验分享

正确更换步骤如下：

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

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

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

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

由社区会员“hp\_hp”分享

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

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

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

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

由社区会员“shizhe1030”分享

EMC DMX存储宕机事件

事件起因：

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

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

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

由社区会员“shizhe1030”分享

Power 570 595宕机

事情起因：

由于机器宕机是在周六，是客户的核心应用，但周六客户没有人上班，当周一上班的时候发现所有的办公，邮件系统等一半的核心应用不能访问，经过现场机房管理人员的临时排查，发现小机Power595后面所有的I/O柜掉电，Power570黄灯亮起，绿灯慢闪当工程师到达现场之后发现，按照与客户沟通好结果，我们开始干活，大概折腾了6个小时，Power595 还是没有启动起来，但power570可以正常访问了，为了赶紧让客户生产数据，我们临时决定，用power570临时做个lpar让存储链接过来，先拉起应用，再又折腾了3个多小时之后，所有应用都可以正常访问，我们继续排查Power5 595 我们更换了CEC DCA 内存板，CPU 都没有解决问题，最后更换了pubook问题解决了，花费时间3天。

问题原因：

电工改造线路，造成了机房断电，UPS临时接管，由于电池放了太久，机器功率太大，造成低电压运行，造成设备不能正常工作，更为关键的是电工出现问题之后没有及时检查电路，根据师傅的陈述大概过了1分钟又把交流电送出去，这个电压冲击是很厉害的，经排查此电工无证施工，客户已经提起诉讼。

由社区会员“shizhe1030”分享

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

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

大致过程：

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

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

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

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

5、收集证据，接近真相

原因：

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

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

教训：

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

由社区会员“mmsc5166”分享