目录 声明 (1) HP (2)
1 复杂案例分析 (2)
1.1 VA多个部件先后发生故障 (2)
1.2 FC60一个部件发生故障后未及时解决造成故障扩大 (3) 1.3 SWAP区空间不够引起系统挂起 (3) 1.4 VA单个控制器不稳定影响应用 (7) 1.5 DS2300控制器故障系统宕机 (8)
1.6 主机GSP的firmware版本低造成自动重启 (9) 1.7 主机故障造成SCSI ID重置，引起SCSI ID冲突 (10) 1.8 informix数据库在切换后未能及时变为“ONLINE”状态造成双机切换不成功 (11)
1.9 系统板的不稳定造成主机多次重启 (13) 1.10 FC60多个部件故障 (14) 2 普通案例分析 (18)
2.1 系统参数设置引起内存不够现象 (18) 2.2 根盘故障导致系统挂起 (18) 2.3 CPU故障引起系统宕机 (19)
2.4 CORE IO板故障引起SCSI Reset报错 (20) 2.5 Service Monitor线路板故障引起风扇报错 (20) 2.6 VA背板故障引起两条光纤环路相继报错 (21) 2.7 FC60电池用尽引起错误告警 (21)
2.8 主机GSP固件版本较老引起Core Dump失败 (22)
2.9 主机和存储间光纤环路故障引起EMQ frozen interrupt报错 (22)
2.10 主板故障引起主机启动失败 (23) 2.11 CPU故障引起主机重启 (23)
2.12 VA电源模块故障一例 (23) 2.13 AutoRaid硬盘故障 (24) 2.14 FC60硬盘故障 (24)
2.15 CPU故障引起主机产生HPMC (24)
2.16 主机MainBoard故障引起系统Panic并产生HPMC (25) 2.17 VA控制器故障引起部分存储设备无法访问 (25) 2.18 EMS告警误报 (26)
2.19 FC60 BCC故障引起部分硬盘无法访问 (26) 2.20 系统核心参数优化降低系统内存占用率 (27) 2.21 主机系统主板故障引起主机挂起 (27) 声明
Copyright ?2004 华为技术有限公司 版权所有，保留一切权利。
非经本公司书面许可，任何单位和个人不得擅自摘抄、复制本书内容的
部分或全部，并不得以任何形式传播。
、HUAWEI?、华为?、C&C08?、EAST8000?、HONET?、?、视点?、ViewPoint?、INtess?、ETS?、DMC?、TELLIN?、InfoLink?、
Netkey?、Quidway?、SYNLOCK?、Radium?、雷霆?、M900/M1800?、
TELESIGHT?、Quidview?、Musa?、视点通?、Airbridge?、Tellwin?、
Inmedia?、VRP?、DOPRA?、iTELLIN?、HUAWEI OptiX?、C&C08
iNET?、NETENGINE?、OptiX?、iSite?、U-SYS?、iMUSE?、 OpenEye?、Lansway?、SmartAX?、边际网?、infoX?、TopEng?
均为华为技术有限公司的商标。
对于本手册中出现的其它商标，由各自的所有人拥有。
由于产品版本升级或其它原因，本手册内容会不定期进行更新。除非另
有约定，本手册仅作为使用指导，本手册中的所有陈述、信息和建议不
构成任何明示或暗示的担保。 HP
1 复杂案例分析
1.1 VA多个部件先后发生故障 故障主机系统及用户 智能网scp 故障现象
主机连接的VA7400无法正常访问。 故障分析和解决方案
1、从磁盘阵列日志可以看出，从8月29日下午14:16起，控制器c1所在光
纤环路就开始出现报错（BACK_SCSI_EVENT_EH）。到8月30日，系统
日志syslog.log中开始出现“PV Powerfailed”和“Write Error”报错。到9
月1日，用户应用出现异常。
2、另外，从磁盘阵列日志还可看出，除环路c1有大量
BACK_SCSI_EVENT_EH报错外，环路c2和子盘箱JA0也有少量此类报错，
由于在维修时发现硬盘JA0/D13故障，可以推断D13故障是导致c2报错的
原因。
3、在更换控制器c1和硬盘JA0/D13后，相关报错不再发生，故障已经基本
修复。
根据上述的分析，本次故障发生的原因是控制器c1和硬盘
JA0/D13均发生故
障，造成c1和c2两条光纤环路都出现不稳定状态，导致数据访问缓慢，使
得应用出现异常。
光纤环路不稳定的故障会随着时间的延续而加重，在8月29日第一次发生后
的一段时间内尚未影响数据读写。但在1天后开始造成系统日志报错，到9
月1日时最终造成应用异常。 更换相应的故障控制器和硬盘
1.2 FC60一个部件发生故障后未及时解决造成故障扩大 故障主机系统及用户 scp1a磁盘阵列FC60 故障现象
磁盘箱1所有硬盘无响应。 故障分析和解决方案
通过现场检查和日志分析，我们确认本次故障的原因是位于磁盘箱1的硬盘
3:2故障造成的。从日志中可以看出，从10月14日起硬盘3:2就已经出现大
量“Unrecovered Error”报错。这种情况持续一天后，磁盘箱1的所有部件
均发生离线。
根据这种情况分析，我们判断硬盘3:2出现了短路故障，造成整个磁盘箱1
电压状况异常，最后使得磁盘箱发生了自动保护性关机。在拔出硬盘3:2并重
启磁盘箱1后，故障现象消失。这也印证了3:2故障的判断。 更换故障的硬盘，故障消除。 1.3 SWAP区空间不够引起系统挂起
故障主机系统及用户 智能网mscp双机 故障现象
11月28日业务中断，12月20日双机切换 故障分析和解决方案
根据日志分析，HP诊断是由于swap空间不过造成。建议增加swap区空间。
华为当时同意先检查自己的应用并采取措施。具体诊断结果如下： 1. problem on Nov 28 0:40 syslog:
Nov 28 00:57:26 mscp2 cmcld: Service mscp_service terminated due to an
exit(1). <-------- pkg down due to service script exit. Nov 28 00:57:26 mscp2 cmcld: Service mscp_service in package mscppkg has
gone do wn.
Nov 28 00:57:26 mscp2 cmcld: Disabled node mscp2 from running package
mscppkg.
Nov 28 00:57:26 mscp2 cmcld: Executing '/etc/cmcluster/mscppkg/control.sh stop' for package mscppkg, as service PKG*56321.
Nov 28 00:58:36 mscp2 cmcld: Service PKG*56321 terminated due to an
exit(1).
Nov 28 00:58:36 mscp2 cmcld: Halted package mscppkg on node mscp2.
Nov 28 00:58:36 mscp2 cmcld: Package mscppkg halt script exited with
NO_RESTART.
Nov 28 00:58:36 mscp2 cmcld: Examine the file /etc/cmcluster/mscppkg/control.sh. log for more details.
Nov 28 00:58:36 mscp2 cmcld: Switching disabled on package mscppkg.
pkg log:
etc/cmcluster/mscppkg/mscp_service.sh[201]: function failed.
There is <------- service script down due to no enough memory
not enough memory available.
/etc/cmcluster/mscppkg/control.sh[612]: The fork function failed. There
is not e
nough memory available.
cu halt the package on mscp2, and switch it to mscp1. and they switch
back on 2:00 clock.
2. problem on Nov 28 10:46 syslog:
ov 28 10:46:30 mscp2 CM-CMD[7055]: /usr/sbin/cmmodnet -r -i 139.104.4.20
139.10 4.4.0
Nov 28 10:46:31 mscp2 cmcld: Service mscp_service terminated due to an
exit(1). <---- again
Nov 28 10:46:31 mscp2 cmcld: Service mscp_service in package mscppkg has
The
fork
gone do wn.
package log:
ksh: no memory: Not enough space
ksh: no memory: Not enough space <------------------ again /usr/lib/dld.sl: Call to mmap() failed - BSS /usr/lib/libcurses.1 /usr/lib/dld.sl: Not enough space sh: 29807 Abort(coredump)
########### Node \"mscp2\": Halting package at Fri Nov 28 10:35:43 EAT 200
3 ###########
Nov 28 10:35:43 - Node \"mscp2\": Halting service mscp_service
/usr/lib/dld.sl: Call to mmap() failed - BSS /usr/lib/libcma.2 /usr/lib/dld.sl: Not enough space ...
/etc/cmcluster/mscppkg/stop_mscp.sh[21]: cannot fork: no swap space <----swap space is not enough
/etc/cmcluster/mscppkg/stop_mscp.sh[22]: cannot fork: no swap space
/etc/cmcluster/mscppkg/stop_mscp.sh[20]: terminatedDeath of ChildSto
pped process continuedEM
ERROR: Function customer_defined_halt_cmds ERROR: Failed to HALT customer commands
########### Node \"mscp2\": Package halt failed at Fri Nov 28 10:36:47 EAT 2003 ###########
3. system swap usage when cu run application mscp2:/#swapinfo -t Kb Kb Kb PCT START/ Kb
stopped
or
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME dev 1048576 0 1048576 0% 0 - 1 /dev/vg00/lvol2 reserve - 1048576 -1048576
memory 3341720 3286872 54848 98% total 4390296 4335448 54848 99% - 0 - 12月20日故障分析如下：
根据日志分析，HP诊断同样是由于swap空间不过造成。建议增加swap区空间。
mscp2# ll core*
-rw------- 1 root root 95644 Dec 20 01:59 core
-rw------- 1 root sys 95644 Dec 20 11:13 core20031220 Check pkg log:
########### Node \"mscp2\": Package start completed at Sun Nov 30 06:12:1 3 EAT 2003 ###########
/usr/lib/dld.sl: Call to mmap() failed - BSS /usr/lib/libc.2 /usr/lib/dld.sl: Not enough space <----swap space is not enough informix down! at Sat Dec 20 01:59:12 EAT 2003
2003Dj12TB20HU PGFZAy, 01:59:40 Start mscppkg customer cmd begin!
########### Node \"mscp2\": Halting package at Sat Dec 20 01:59:21 EAT 200 3 ###########
Dec 20 01:59:21 - Node \"mscp2\": Halting service mscp_service
cmhaltserv : Service name mscp_service is not running. Sat Dec 20 01:59:21 EAT 2003 Stop mscppkg customer cmd begin! cmmodnet : Subnet 139.104.4.0 is not a configured subnet.
cmmodnet : Use the \"netstat -in\" command to list the configured subnets. 2003Dj12TB20HU PGFZAy, 01:59:49 Start mscppkg customer cmd begin!
lan1:1 1500 139.104.4.0 139.104.4.20 462 0
Stop scp ok!
因为两台N4000的主机内存都是4GB，而SWAP区（/dev/vg00/lvol2）只有1GB,SWAP区空间不够，一旦内存中应用所需要交换的数据超过SWAP区的大小，内存中的数据就会等待SWAP，从而有可能致使内存中应用部分所需交换的数据不能释放，占据内存空间，从而导致内存使用量大，所以应用HANG住或不能启动。
除了需扩充SWAP区，为保证系统今后不再报“out of memory”同时又能充分发挥HPUX 64BITS 计算的优势，HP还建议华为检查当前系统的以下核心参数（maxdsiz >0x40000000 , maxdsiz_64bit>0x400000000
，
maxswapchunks>10000
,
dbc_max_pct<20)，以下是建议检查并修改参数的原因。
maxdsiz--- Max Data Segment Size For 32-bit Processes (Bytes)
maxdsiz_64bit--- Max Data Segment Size For 64-bit Processes (Bytes)
---如果一个32bit或64bit进程要占用的内存较大，就需要调整以上两个参数，否则应用进程就会异常退出。
maxswapchunks --- Max Number of Swap Chunks ---如要加SWAP区，就必须调大此参数。
dbc_max_pct---Max Dynamic Buffer Cache Size as Percent of System RAM Size
---即被分配给文件系统用的缓存在当前主机内存中占用的比例，由于华为的应用基本是裸盘访问，故应调小此参数以便应用有更多的内存可以使用。
综合两次的日志分析，都是由于swap空间不够造成。建议增加swap空间。
1、如果根盘有多余的空间，可以在线添加一个2级swap区，然后在线做镜像。如果根盘满了可以在外置存储上找空间，在线添加一个2级swap区。这些操作都可以通过SAM在线的快速实现。操作本
身可以立即生效，不会对应用造成影响。但是如果在外置存储建立2级swap区，如果外置存储发生故障可能导致系统hang。如果有双存储可以考虑两个存储上各建一个swap区，然后做镜像。具体方案需要和华为共同进行测试。
2、建议检查并修改以下核心参数：（maxdsiz>0x40000000, maxdsiz_64bit>0x400000000
，
maxswapchunks>10000,
dbc_max_pct<20），为保证系统有足够的内存，应检查参数“swapmem_on”，如是“1”，应改为“0”，“swapmem_on”如设为“1”是当内存非常大但根盘的SWAP区不够大时，使系统能使用部分内存来做SWAP区，但这会占用大量的内存，所以我们建议在根盘上加上足够大的SWAP区后，务必检查此参数，保证它是“0”。
1.4 VA单个控制器不稳定影响应用 故障主机系统及用户 智能网SDP 故障现象
磁盘阵列VA7400无法访问 故障分析和解决方案
在对磁盘阵列日志进行分析的过程中，我们发现在2月1日凌晨5点左右磁
盘阵列出现“Backend SCSI Event”报错。操作系统在上午9点发现磁盘阵
列数据不可用。经过分析，我们确认本次故障是由控制器c2发生故障造成的。
在VA7400的设计中，当一个控制器损坏时，另一个控制器将接管其工作，
磁盘阵列仍能正常访问。但本次故障情况比较特殊，控制器c2并未完全损坏，
而是处于不稳定的临界状态，使得整个环路中不断出现“Backend SCSI
Event”报错，c1始终没有对其进行接管。这种状态持续了数小
时后，最终造
成光纤环路堵塞，磁盘阵列出现hang机状态，LUN也无法访问。在这种情
况下，拔出控制器c2，使环路c2断开，环路c1就可以恢复正常工作。
上述问题在控制器固件版本为HP18以下时发生的可能性较大。而这台
VA7400的控制器版本为HP16。
在更换了控制器c2后，磁盘阵列故障已经修复。同时升级控制器固件版本到
HP18。
1.5 DS2300控制器故障系统宕机 故障主机系统及用户 智能网VC 故障现象 双机锁盘不能访问 故障分析和解决方案
锁盘故障是一种比较难于定位的SCSI问题。涉及的部件包括硬盘、SCSI电
缆、DS2300总线控制器乃至主机端的SCSI卡，其中硬盘和SCSI电缆故障
的可能性较高。在处理此类故障时，通常要采取替换备件和日志分析相结合
的方法，进行多次测试以定位故障原因。
在本次故障处理中，在更换硬盘未能排除故障后，工程师根据常规方法对SCSI
电缆进行了更换测试，但在执行ioscan测试过程中发生了SCSI故障导致备
机突然宕机，而主机在发现备机宕机后采取了抢锁盘重组集群的动作，但由
于锁盘尚未修复，造成重组失败，最后主机也被TOC宕机。 在一般情况下，在线更换和拔插SCSI电缆并进行ioscan测试只会造成SCSI
Reset报错，不会对系统运行造成影响。但在本次故障中锁盘盘箱（DS2300）
的总线控制器存在故障，这种故障是一种SCSI不稳定状态，使得备机在执行
ioscan时发生IO堵塞，造成系统crash。
需要说明的是，DS2300控制器并未完全损坏（ioscan能够看到控制其本身
并且指示灯均正常），只是在SCSI通道中存在不稳定状态。这对我们的诊断
也造成了一定的困难。
根据上述分析和故障处理的过程，我们得出结论：本次双机宕机的原因是
DS2300的总线控制器存在故障导致测试SCSI电缆时备机crash，进而造成
主机TOC。同时DS2300控制器故障也是锁盘无法找到的原因。 在总结了本次的经验和教训后，我们将在以后的工作中注意以下几点：
(1) 严格遵守用户对维修时间的要求，在业务空闲的时段进行服务。 (2) 在服务过程中与华为工程师密切配合，并在实施操作前充分沟通。
(3) 凡是涉及到双机锁盘SCSI链路（更换硬盘除外）的维修与诊断，要事
先停止备用节点（cmhaltnode）再进行相关测试，避免因备机宕机而造
成主机重组。
(4) 双机宕机的应急处理方案：一般来说，双机运行是比较可靠的。但当出
现某些意外情况时，如某个节点故障的同时锁盘失灵时，双机有可能同
时宕机，对于这种情况，应采取以下措施迅速恢复业务： z关闭锁盘盘箱电源
z立刻强制重起两台主机，有可能其中一台主机无法正常启动 z主机重起成功后在正常的那台主机上单节点启动集群 cmruncl –v –n 主机名
z联系惠普响应中心进行后续处理 更换DS2300总线控制器故障排除。
1.6 主机GSP的firmware版本低造成自动重启 故障主机系统及用户 智能网主机 故障现象
2002//11/15 至 2002/11/20之间，L3000（备机）自动重起了两次，无任何
故障软硬件日志记录，每次重启动后可以正常工作。 故障分析和解决方案
经过北京响应中心的诊断，同时升级问题到全球支持中心，根据WTEC的建
议，HP工程师于2002年11月27日为该机安装了补丁程序并进一步等待
WTEC的结果。2002年12月17日，WTEC建议升级该主机的GSP的
firmware版本，由原来的B.02.07 升级到最新的B.02.17，可以解决这个问
题。
升级该主机的GSP的firmware版本，由原来的 B.02.07 升级到最新的
B.02.17后故障排除。
1.7 主机故障造成SCSI ID重置，引起SCSI ID冲突
故障主机系统及用户 智能网scp 故障现象
双机中报大量SCSI Reset错误，应用进程挂死导致呼叫中断 故障分析和解决方案
经过现场检查和远程诊断，我们发现在主机凌晨2点重起以后，主机开始大
量报SCSI reset，到凌晨6点备机重起后，SCSI reset报错在主机上消失，
而备机开始大量报SCSI reset错误。在更改SCSI ID并重起系统后，SCSI
reset报错不再发生。
经过检查系统安装后的信息收集文件，我们确认安装时已将两块SCSI卡的ID
改为了6（主机）和7（备机）。但现场处理时发现主机的SCSI ID从6变为
了7，造成SCSI ID冲突。
根据上述分析和日志检查的结果，现有如下结论：
(1) 应用进程异常是由于SCSI IO通道出现大量reset造成的。这种报错只
出现在一台主机上，但造成两台主机的SCSI通道都发生堵塞。进而使
得后续的IO请求无法响应。
(2) 主备机连接锁盘的SCSI卡的SCSI ID冲突导致了SCSI reset的发生，
这也是造成双机同时宕机的原因。
(3) 目前判断SCSI ID冲突并非人为造成，根据惠普全球响应中心的分析结
果，确认储存在主机SCSI卡上NVRAM中的SCSI设定在某次重起后
丢失，造成SCSI ID变回默认值7。
(4) 在对宕机时产生的Coredump日志进行分析后，我们发现锁盘在被访问
时有时有无法响应的现象，由此判断锁盘本身也存在不稳定的问题。虽
然该问题并未导致宕机，但也需要及时修复。
根据上述分析，本次故障是由SCSI ID冲突造成的。由于目前SCSI ID已经
更正，目前系统可确保稳定运行。为彻底排除故障隐患，我们有如下处理方
案
z更换主机的SCSI卡。
z更换连接主备机的锁盘。更换时需要同时停止双机约1小时。 z更换后对主备机SCSI设定进行检查，确认相关设定正常。 1.8 informix数据库在切换后未能及时变为“ONLINE”状态造成双机切换不成功
故障主机系统及用户 智能网主机mscp1 故障现象
主机发生HPMC自动重起，应用切换到备机后出现异常 故障分析和解决方案
本次故障共有两个问题：一是mscp1发生了HPMC宕机；二是mscp2在切
换后应用不正常。根据响应中心的诊断，对这两个问题有如下分析：
1. mscp1发生HPMC
HPMC（High Priority Machine Check）是系统在发生关键硬件（CPU、IO等）
故障后自动重启的自检过程。通常情况下发生HPMC都意味着硬件故障的发
生。
HPMC在系统完成自检后会保存日志文件ts99供分析。经专用的HPMC分
析器分析后，得出诊断如下：
Possible Cause 1: LBA chip failed or IO backplane failed. Possible Fix 2a: Replace PCI backplane connected to cell 0x1 (1).
Possible Fix 2a: Replace PCI Backplane connected to cell 0x1 (1).
Possible Fix 2a: Replace PCI Backplane connected to cell 0x1 (1).
Possible Cause 2: PCI card failed.
Possible Fix 1: Replace PCI card in PCI backplane slot 6 connected to
cell 0x1 (1).
根据分析器的结论，发生HPMC的原因可能有两个： (1) PCI Backplane发生故障
(2) 位于slot6的10/100BT网卡（硬件路径1/0/4/0/0）发生故障
其中原因1的可能性较大。由于本次故障影响较大，为确保一次性修复故障，
现决定同时更换PCI Backplane和网卡。 2. 切换后应用不正常
切换发生时mscp2上的包日志文件如下：
########### Node \"mscp2\": Starting package at Mon Sep 8 18:02:21 EAT 2003
#######
Mon Sep 8 18:02:21 EAT 2003 Start mscppkg customer cmd begin!
Informix is not primary state!
Floating ip isn't added!
Mon Sep 8 18:03:24 EAT 2003 Start mscppkg customer cmd complete!
Sep 8 18:03:24 - Node \"mscp2\": Starting service mscp_service using \"/etc/cmcluster/mscppkg/mscp_service.sh\"
########### Node \"mscp2\": Package start completed at Mon Sep 8 18:03:24 EAT 2003 #
发现在执行start_mscp_sh的时候发生“Informix is not primary state!”和“Floating ip isn't added!”报错，检查start_mscp_sh，有如下语句：
while [ $counter -lt $check_times ] do
su - informix -c \"onstat -\" | grep \"On-Line\" | grep -v grep >/dev/null ret=$?
if [ $ret -eq 0 ] then
/usr/sbin/cmmodnet $FLOAT_IP_NET >/dev/null
if [ $? = 0 ] then
echo Add Floating IP ok! >> $LOG fi break else
sleep $check_interval counter=`expr $counter + 1` fi done fi
if [ $counter -eq $check_times ]
-a
-i
$FLOAT_IP
then
echo \"Informix is not primary state!\" >> $LOG echo \"Floating ip isn't added!\" >> $LOG else
#send sigusr1 to main machine
kill -16 `ps -f -u $MSCPUSER | grep \"manager\" | grep -v grep | awk {'if($3 =
= 1) print $2'}` >/dev/null
echo \"Send SIGUSR1 to scp ok!\" >> $LOG fi
经检查，在切换发生后，应用在等待数据库变为“ONLINE”状态，但在60
秒后，数据库状态仍未变为“ONLINE”，造成浮动IP加载失败。 因此，切换不成功的原因是备机informix数据库在切换后未能在60秒内变为
“ONLINE”状态。
根据以上分析结果，我们有如下维修方案 (1) 同时更换mscp1的PCI Backplane和网卡
(2) 由informix方面检查数据库不能及时online的原因，并做出相应调整。
1.9 系统板的不稳定造成主机多次重启 故障主机系统及用户 惠普N4000主机mscp1 故障现象
主机发生HPMC，造成宕机 故障分析和解决方案
HPMC（High Priority Machine Check）是在系统关键硬件（如系统板、IO背
板、CPU和内存等）发生异常时，系统进行自动重起并自检的一种保护性措
施。系统在发生HPMC重起后，会在/var/tombstone目录下生成日志文件tsxx
供工程师进行诊断。通常HPMC发生时系统重起后仍能保持一段时间的正常
运行，但随时都有再次宕机的可能。
我们诊断HPMC问题的方法是将生成的ts99文件上载到惠普全球专门的网站
上，并自动得出分析结论。分析结论是在对日志文件进行解码后，根据相关
部件出现故障的概率高低得到的。这种诊断方法的准确性是比较高的，但有
时也会遗漏一些可能性较小的部件。对于较为复杂的问题来说，还需要综合
其他系统日志，并参考相关维修历史进行故障判断，有时还需要手工对日志
进行分析。
对于本次的故障来说，从4月30日到5月5日，mscp1一共发生了四次HPMC，
生成了4个日志文件（ts96,ts97,ts98,ts99）。4月30日生成的ts96指示左
侧IO背板有故障，5月1日生成的ts97和ts98以及5月5日生成的ts99都
表明系统板和CPU2存在故障。
在响应中心技术专家对4次日志进行综合分析后，发现事实上第一次生成的
日志文件ts96中也存在系统板故障的可能，但由于当时故障发生于系统总线
与IO的通路之间，故工程师和分析网站都认为IO背板故障的可能性较大（至
于PDC版本升级，并不针对本次故障，而是借停机的机会采取的
预防性措施，
有利于以后的故障诊断）。而后来的故障发生于系统总线和CPU之间，因此
后来的日志指出CPU和系统板可能有故障。这也就是两次诊断结果相差较大
的原因。
综合以上的分析，我们得出的结论是，本次故障的真正原因是系统板，IO和
CPU的异常都是由于系统板的不稳定所致。在更换了相关部件后，故障隐患
已经排除。
1.10 FC60多个部件故障 故障主机系统及用户 客服系统N4000双机 故障现象
FC60多块硬盘无法访问，Oracle数据库无法启动 故障分析和解决方案 1. 故障发生过程分析
这台FC60共划分了3个LUN，划分方式如下： LUN Raid级别容量包括的硬盘 2:0, 3:1, 4:0, 3:0 1:1, 1:0, 0 5 84.6GB 4:1 2:1, 1 1 16.9GB 3:2 2 1 16.9GB 1:2,
硬盘分布如下表： 槽位0 1 2 3 4 5 6 7 8 9 盘箱1 1:0 2:0 1:1 2:1 1:2 盘箱2 3:0 4:0 3:1 4:1 3:2 图例： 颜色 LUN 0 1 2
响应中心分析了磁盘阵列的日志（amlog），有如下报错记录： Controller log sense for Subsystem 000400A0B8093FEC at Sat Aug 2 10:45:32
2003
Controller Time Stamp = 080203 024251 FRU Code = 0x21
FRU Code Qualifier = 0x0000 Sense Key = 0x06
Additional Sense Code = 0x3F Add Sense Code Qual = 0x80
Decoded Field Replaceable Unit Information: FRU Group = Disk Group SCSI Channel:ID = 2:1 Decoded SCSI Sense:
The controller set the disk state to \"Failed - Write failure\" Reporting LUN = 1
Controller log sense for Subsystem 000400A0B8093FEC at Fri Sep 19 06:25:19 2003
Controller Time Stamp = 091803 222513 FRU Code = 0x40
FRU Code Qualifier = 0x0000 Sense Key = 0x06
Additional Sense Code = 0x3F Add Sense Code Qual = 0x80
Decoded Field Replaceable Unit Information: FRU Group = Disk Group SCSI Channel:ID = 4:0 Decoded SCSI Sense:
The controller set the disk state to \"Failed - Write failure\" Reporting LUN = 0
Controller log sense for Subsystem 000400A0B8093FEC at Fri Sep 19 16:09:36 2003
Controller Time Stamp = 091903 081103 FRU Code = 0x20
FRU Code Qualifier = 0x0000 Sense Key = 0x06
Additional Sense Code = 0x5D Add Sense Code Qual = 0x80
Decoded Field Replaceable Unit Information: FRU Group = Disk Group SCSI Channel:ID = 2:0 Decoded SCSI Sense:
Disk SMART Event (Self-Monitoring Analysis and Reporting Technology) Reporting LUN = 0
从上述记录可看出，2:1早在8月2日就已经开始有“write failure”报错，而在9月19日早上6点25分4:0也出现“write failure”报错。在下午4点左右，硬盘2:0则被控制器发现有SMART错误。
从前面的LUN划分可以看出，2:1属于LUN1（锁盘），并不影响数据。而4:0和2:0同属LUN0，也就是oracle数据所在的LUN，由于同一个LUN的两块硬盘都出现故障，造成该LUN的数据读写发生异常，并最终导致了相关数据不一致。
2. 故障发生原因分析
2:1和4:0的报错都是“write failure”，这是在控制器向硬盘写数据时发生了错误，这时控制器会将该硬盘置为“failed”或“No Response”状态，不再向该硬盘进行写操作。当1块硬盘发生这种故障时，整个LUN会变成“degrade”状态，性能也会有明显下降，但数据访问仍能够正常进行。
2:0的报错信息是SMART（Self-Monitoring Analysis and Reporting Technology），即硬盘自身的检测机制发现异常，这种检测机制是磁盘制造厂商（如seagate）定义的一种扩展标准，这通常意味着磁盘本身的故障。而在控制器版本较低（如HP03）的情况下，这种故障经常会被控制器忽略，也不会将其置为“fail”状态，而会继续向该硬盘进行写操作。
综合上述两点，在4:0被控制器置为“No response”后控制器继续向2:0写数据，但2:0也存在磁盘故障，使得写入的数据存在错误，这样就导致了数据的不一致。
由于SMART错误在HP03的控制器上经常被忽略，因此并不能根据日志来判断2:0出故障的时间，而根据现场故障发生及处理的过程来看，2:0应该是在4:0故障之前就出现问题了。
在维修过程中，4:0更换后出现rebuild失败，这只会在同一LUN中有另一块硬盘（如2:0）损坏时才会发生。这也证明了上述的判断。对于2:1来讲，只是一次普通的硬盘故障，并未影响数据访问。
由此可见， 4:0出现故障，加上HP03的控制器未能及时发现2:0的SMART 报错，是造成LUN0数据不一致的原因。
3. 近期故障问题分析
从7月17日到9月19日，这台FC60出现了3次故障： 7月17日，FC60关电重起后4:0、1:0、3:1出现“write failure”报错，经诊断后确认是启动时磁盘箱和控制箱加电相隔时间过短，加上磁盘阵列控制器版本低造成的。并已建议升级控制器的版本到HP12。
z7月29日，硬盘4:1发生故障，更换后解决。
z9月19日，本次故障发生，更换了2:0、4:0、2:1并升级控制器
版本到HP12后修复。
从上述故障来看，7月17日的故障与硬盘故障无关，与控制器版本有关；7月29日和9月19日的故障都是硬盘故障，并分布在不同的硬盘上，其中本次故障也与控制器版本有关。
另外，经现场工程师的观察，用户机房环境的灰尘较多，尤其是FC60的硬盘上灰尘比较明显。对于硬盘这种高速旋转的磁介质设备来说，灰尘对设备的稳定运行影响较大。
由此，我们得出如下判断：
z本次故障和7月17日的故障都与控制器版本较低有关。 z对于硬盘频繁故障的问题，我们怀疑与设备灰尘较多有关。 根据上面诊断和分析的结果，我们有如下结论和建议：
z目前控制器的版本已经升级到了HP12，并更换了相关硬盘，本次故障的隐患已经排除。
z由于近期硬盘损坏较多，建议对该台磁盘阵列进行除尘，同时采取措施改善机房的清洁状况。
z建议相关管理人员加强对系统运行状态的监控，以便能够及早发现并解决问题。对于FC60状态的监控，可执行命令：amdsp –a fc60。
2 普通案例分析
2.1 系统参数设置引起内存不够现象 故障主机系统及用户 移动智能网SCP备机 故障现象
绝大部分内存已被系统占用(size是2Kb的bucket占用了1.6GB的内存)，从
而导致应用无法再次启动。 故障原因分析及解决方案 1. 原因分析
由于备机的系统参数“vx_ninode”和“VX_NOIFREE”都是“0”，无法防
止过多的“vxfs”文件系统的inode请求不断占用内存，在某种
情形下，当有过
多的inod请求时就有可能最终导致内存不够的现象出现。 2. 解决方案 更改系统参数
“vx_ninode”从“0”到“8000-16000” “vx_noifree”从“0”到“1” 2.2 根盘故障导致系统挂起 故障主机系统及用户 无线智能网系统smp 故障现象
SMPHANG 机挂起，无论是从主或从根盘都无法重新启动 故障原因分析及解决方案 1. 原因分析
(1) 由于主根盘的硬盘控制器损坏而导致主根盘无法引导。 (2) 又由于根盘镜象补丁未打，而导致从根盘无法顺利接管，也无法在单盘
情况下成功启动（以前虽做过测试，但测试时都是在主盘能正常工作的
情况下进行的，故不是很全面）。
因篇幅问题不能全部显示，请点此查看更多更全内容