前端时间有人问我小型机出现故障之后怎么去找问题，但是之前出差比较忙，今天我就好好的将这个整理一下。希望大家看到之后有什么不到位的地方可以补充下。
第一、先定义故障
弄清楚系统发生了什么问题
系统现在能做什么？不能做什么？
故障什么时候发生的？
有没有做平时不同的操作？
故障有没有规律？定时还是不定时？发生的频率有多高？
是一台机器出现故障还是多台机器故障？故障现象是否相同？
最近有没有做改动？如安装了新的硬件、软件，改变了系统的一些设置。
第二、对故障进行故障信息收集
1) 收集故障信息对于判断、诊断故障原因，修复系统非常重要。
2) 系统故障记录(errorlog)
errdemon 进程在系统启动时自动运行
记录包括硬件、软件及其他操作信息
故障记录文件为/var/adm/ras/errlog，可备份下来或拷贝到别的机器上分析
errpt 命令的使用(普通用户权限也可使用)
# errpt |more 列出简短出错信息
3) 控制面板上的LED 代码
8 位代码，通常系统故障灯会同时亮起。某些机型还会同时显示故障设备位置代码。
4 位代码，通常是Exxx。
3 位代码，通常为0yyy，只看后3位。
8 位和4位代码可查看系统服务手册 (Service Guide)。
4) SMS (System Management Service) 故障记录
如何进入SMS 菜单
当主控台出现键盘图标后(LED 显示E1F1时)按1键。
选择"Utilities"，选择"Error Log", 抄下8位故障代码（在SMS 中还可以更改系统启 动顺序表）
5) MAIL
# mail
系统会向root用户发mail报告出错信息。通常系统出现故障后没有进行检查修复，系统会定时提醒root。
6) 运行故障诊断程序(Diagnostic)，对系统硬件进行检查和诊断。
当发现有硬件故障时应立即使用diag
#diag
> 选高级诊断（Advance Diagnostic)
> 选问题诊断（Problem Determination) 或 选系统检查（System Verification)
(选PD 会对系统错误记录进行分析)
diag运行后会给出SRN 代码，故障设备名称及百分比，地址代码等。
对于PCI机型应在系统报错7天之内运行diag程序对出错记录里的sense数据进行分析。
7) 其他用于收集系统信息的命令
lsdev -C 系统设备信息
lspv 查看物理卷信息 还有其他的。。。
第三、硬件故障定位
IBM 小型机故障定位方法包括小型机I/O柜上的显示面板上的Checkpoints信息，Error Code 和SRNs。
Checkpoints 检查点是系统加电CMOS初始化程序(initial program load (IPL))运行后显示在 I/O柜的显示面板上一系列信息。
1. IPL 流程
当交流电源接到系统后，IPL流程就开始了，IPL流程包括四个步骤：
. Phase 1: Service Processor 的初始化
Phase 1 开始于交流电源接到系统后，直到OK显示在I/O柜上的显示面板上为止。在这个步骤会显示 8xxx 或9xxx checkpoints代码 。
. Phase 2: 由 Service Processor 引导的硬件初始化
Phase 2 开始于按下I/O柜上的白色电源开关。在这个步骤会显示 9xxx checkpoints 。91FF 是最后的代码标志着第三步骤的开始
. Phase 3: 系统固件的初始化
在 Phase 3, 一个系统处理器接管控制并继续初始化系统资源， 在这个步骤会显示 Exxx。E105是最后的代码标志着第四步骤AIX启动的开始。在这个过程中还会显示各种位置码（ 位置码代表着系统的每一个部分）
. Phase 4: AIX 启动
当AIX开始启动时，显示面板上的代码为 0xxx ，同时位置码会出现在第二行。当AIX的登录窗口出现在控制台上时第四步骤结束同时显示面板上再无任何信息出现。
Error Code 当系统运行有错误发现时，一个8位码会显示在显示面板上，同时在第二行显示相对应问题硬件的位置码。
SRNs （Service request numbers,服务请求码 ）当系统运行有错误发现时，SRNs码会以 xxx-xxx的形式显示在显示面板上，同时在AIX的error log中也会有记载。
以上所有代码都会有相应的步骤解决。由于代码繁多，请在出现问题后记录下代码，并致电IBM服务热线。
2. 系统不能启动
系统停在Stage 1，可能为电源、系统板、CPU、内存等硬件故障。记录故障代码通知IBM工程师。
系统停在Stage 2，可能是启动顺序表(bootlist)损坏或I/O子系统故障。可尝试进入SMS 菜单检查启动顺序表，并修改。若在选择bootlist时没有硬盘设备可选或显示的硬盘信息不正确则可能是硬盘故障。若根本没有SCSI设备可选则链路有问题。
系统停在Stage3，可能是硬盘数据损坏，系统设置文件出错，或I/O子系统故障。
系统停在551，555或557
发生在系统启动的第三阶段 (Stage 3)，可能是：
文件系统损坏
文件系统日志(jfslog)损坏
rootvg中有坏硬盘
3. 修复方法
用系统光盘或系统备份带启动（必须与硬盘中的操作系统版本一致）
启动后选择选项3
"Start Maintenance Mode for System Recovery"
> "Access a Root Volume Group"
> "Access this volume group and start a shell
before mounting the file systems"
格式化文件系统日志(jfslog)
# /usr/sbin/logform /dev/hd8
检查修复文件系统
# fsck -y /dev/hd1 （/home 文件系统）
# fsck -y /dev/hd2 （/usr 文件系统）
# fsck -y /dev/hd3 （/tmp 文件系统）
# fsck -y /dev/hd4 （/ 文件系统）
# fsck -y /dev/hd9var （/var 文件系统）
... ...
用 exit 命令退出，文件系统会自动 mount 起来。
重建bootimage
# lslv -m hd5 找出bootimage所在的硬盘，如hdisk0
# bosboot -ad /dev/hdisk0
# bootlist -m normal /dev/hdisk0 重建启动顺序表。
重启动系统
# shutdown -Fr
如上述步骤不奏效
用系统备份带恢复系统。
如备份带不能恢复，用诊断光盘（Diagnostic CDROM）检查是否坏硬盘。
4. CDE图形界面挂死
CDE 运行时不要更改网络参数（如：主机名和IP 地址）
更改网卡设置，请先退出CDE图形环境，选择命令行方式登录，在字符界面下更改。
如CDE 已经挂死
远程 telnet 登录
找出所有dt有关的进程用kill命令杀掉
# ps -ef |grep dt
... ...
# kill PID
检查当前主机名
# hostname
tscf50
查看主机名是否对应有效的IP地址
# netstat -i |grep tscf50
tr0* 1500 9.185.40 tscf50 506049 0 28247 0 0
更改主机名或IP地址，使主机名与当前有效的IP地址存在对应关系。
# smitty tcpip
重新启动CDE界面
# /etc/rc.dt
HACMP环境下可把主机名alias到127.0.0.1上
# cat /etc/hosts
127.0.0.1 loopback localhost tscf50 # loopback (lo0) name/addressbvg
5. 系统dump
发生在系统崩溃时，AIX会做dump(系统内存的快照)。
此时机器会显示闪动的888 102 xxx 0cx 代码：
0c9 系统dump 进行中。0c9状态可能会维持超过2分钟，
不要关电和按reset, 等待dump做完。
0c0 dump 成功完成，这时可以断电重起。
0c2 手动启动dump 功能
0c4 dump 设备空间不足，只有部分信息保存下来
0c5 不明原因导致dump 失败
一般dump是由于软件出错引起(888-102-207 除外)，机器通常可以重启。重启时可能提示用户插入磁带拷贝dump文件，不要选择退出，这样会丢失重要的故障信息。
dump的有关设置
估算系统dump的大小，在系统最繁忙时（内存使用最多）
# sysdumpdev -e
0453-041 Estimated dump size in bytes: 53477376
# lsps -a
Page Space Physical Volume Volume Group Size %Used Active
paging00 hdisk0 rootvg 480MB 1 yes
hd6 hdisk1 rootvg 544MB 1 yes
当前的设置
#sysdumpdev -l
primary /dev/hd6
第四、软件故障的定位
软件故障情况错综复杂，下面列举几个常见案例的故障处理方法。
1) 文件系统空间不够。
查看有没有“满”的文件系统。特别是/、/var、/tmp，不要超过90%。文件系统满可导致系统不能正常工作，尤其是AIX的基本文件系统。如/ (根文件系统)满则会导致用户不能登录。用df –k 查看。
# df -k (查看AIX的基本文件系统)
Filesystem 1024-blocks Free %Used Iused %Iused Mounted on
/dev/hd4 24576 1452 95% 2599 22% /
/dev/hd2 614400 28068 96% 22967 15% /usr
/dev/hd9var 8192 4540 45% 649 32% /var
/dev/hd3 167936 157968 6% 89 1% /tmp
/dev/hd1 16384 5332 68% 1402 35% /home
除/usr文件系统，其他文件系统都不应太满，一般不超过80%。
处理方法1：删除垃圾文件
# du -sk * |sort -rn |head
查找出当前目录下占空间最大的子目录，逐层往下直到找出占空间最大的文件。（要区分哪些目录是文件系统的 mount point，哪些是文件系统的子目录）删除文件，释放空间。有时删除文件后空间并不马上释放，这是由于你删除的文件正被某个程序打开。只有当这个程序停止后空间才释放，有时甚至需要重起系统。
处理方法2：增加文件系统大小
# smitty chjfs
文件系统可以在任何时候加大，前提是卷组(VG)中有剩余空间。
2) 检查文件系统的完整性
# umount filesystem_name
# fsck -y filesystem_name
注意：文件系统必须先umount，再做检查和修复，否则可导致未
知的后果。
3) 查看卷组信息(lsvg -l vg_name)：
有没有"stale"状态的逻辑卷。 若有，用syncvg 命令修复"stale"逻辑卷。
4) 检查内存交换区(paging space)使用率(lsps -s)：
使用率是否超过70%，若有则用chps –sX pgname增加X个PP或用 mkps –a –n –sX myvg在myvg上增加一个PP数为X的内存交换区。
5) 小型机内存泄漏问题
小型机出现内存泄漏，即系统或应用进程无法将使用过的内存释放，使可用内存的容量逐渐减少。如果可用内存降到某最小值将造成系统或应用程序无法FORK子进程，就会造成系统瘫痪。
通常我们可以用ps和sar命令来查看小型机内存和CPU占用率的大概情况以及各进程的内存和CPU占用率的发展趋势。
第五、HACMP环境下的排错
在一般情况下,HACMP软件很少需要手工干预,但一旦有问题发生,诊断和恢复的技巧是很重要的.需要能很快地断定问题然后运用你对HACMP的理解来恢复HACMP的正常运作.
一般地,HACMP环境下的排错包括:
了解问题的存在.
判断问题的出处.
解决问题.
第六、常用的系统状态查询命令
# lsdev –C –s scsi
列出各个SCSI设备的所有相关信息：如逻辑单元号，硬件地址及设备文件名等。
# ps -ef
列出正在运行的所有进程的各种信息：如进程号及进程名等。
# netstat -rn
列出网卡状态及路由信息等。
# netstat -in
列出网卡状态及网络配置信息。
# df -k
列出已加载的逻辑卷及其大小信息。
# mount
列出已加载的逻辑卷及其加载位置。
# uname -a
列出系统ID 号，系统名称，OS版本等信息。
# hostname
列出系统网络名称。
# lsvg –l rootvg,lsvg –p rootvg
显示逻辑卷组信息，如包含哪些物理盘及逻辑卷等。
# lslv –l datalv,lslv –p datalv
显示逻辑卷各种信息，如包含哪些盘，是否有镜像等。
八 网络故障定位方法
网络不通的诊断过程：
ifconfig 查看网卡是否启动 (up)
netstat –i 查看网卡状态
Ierrs/Ipkts 和 Oerrs/Opkts是否>1%
ping自己网卡地址 (ip 地址)
ping其它机器地址，如不通，在其机器上用diag检测网卡是否有问题。
在同一网中， subnetmask 应一致。
网络配置的基本方法：
(1) 如需修改网络地址、主机名等，一定要用 chdev 命令
# chdev –l inet0 –a hostname=myhost
# chdev -l en0 -a netaddr='9.3.240.58' -a netmask=255.255.255.0’
(2) 查看网卡状态：# lsdev –Cc if
(3) 确认网络地址：# ifconfig en0
(4) 启动网卡：# ifconfig en0 up
(5) 配置路由
有两种方式加入路由：
永久路由
# chdev -l inet0 -a route=’10.47.0.0’,’9.3.240.59’
临时路由
# route add 10.47.1.2 9.3.240.59
用命令 netstat -rn 查看路由表
本文转自 沐小七 51CTO博客，原文链接:http://blog.51cto.com/3088522/1043568
