errpt报错（困惑中）

jlttt

yanbing ,我们有盘阵，不过空间利用的差不多了，最近考虑扩容呢。还有我们这个数据库很大，
EXP导出不是那么容易，1。没有那么多的空间2。没有那么长的时间
不过，经过您的这番讲解，我似乎明白点了，就权当飞机上的黑匣子，一旦出了问题，通过这个黑匣子就能找到问题的原因。
‘dump是指AIX中用于保留crash时系统kernal关键信息的文件’这个文件系统一直就是这么大，都2年了，以前为什么没有出现过这样的错误提示？难道我们的系统要crash，dumpcheck开始做准备活动了？

[ 本帖最后由 jlttt 于 2008-2-25 18:54 编辑 ]

yanbing

我之前看该设备上的文件系统看不到有盘阵的迹象，所以推测没有盘阵，而且2个filesystem的名字叫vg1和vg2也能说明是使用得oracle。因为oracle的安装手册上是以/U01和/U02来推荐的。

这里有个失误，其实关注一下vg1和vg2的size就能看出来是有盘阵存在的。不过这个不是此次问题的重点。

你的疑问是为什么会出现dumpcheck的报错，我们前面也聊过，一旦超过这个尺度限制就会报警。至于kernal信息的总量是在不断增加的，128M的限度，假设前天是127MB的内容，自然不报，今天到了129MB，于是自当报警。这是假设。

而实际上，昨天的停电只是让你们的127变成了129而已。关于dump通常的大小，从10MB到100GB，都是正常的。

别在意这个报警，提示出来了就增加一下，kernal随时都在记录，根据你的应用繁忙程度不同而size不同。活动增加，尺寸扩大是业务变化的迹象，而不是要down机的迹象。

就像你说的黑盒子，，，如果舱音记录嘈杂，那可能是机长碰到了流控，反复在调整进近航线，而不是说马上就要坠机，但是黑盒子里的空间不够的话，如果这时候真的坠机，那就没有原始记录可查了。于是报警出来，提示说尺寸不够了。（哈，我也是航空迷）

yanbing

当然黑盒子是按照时间来记录的，保证存储空间大于飞行时间，这样的话就不会出现空间不够的问题，补充说明一下。

jlttt

哦，我明白了，谢谢版主。不过我还有个问题，今天p570的报警灯亮了是橙色，IBM工程师经过对 snap的分析得出，硬件没有问题，并给我了一个关于清除警报灯的操作。
diag
-> 回车
->Task Selection
->Identify and Attention Indicators
->回车选择 Set System Attention Indicator to NORMAL
->F7 (或者组合键 ESC与7 一起按)提交，OK
其实，这个办法我以前已经试过了，警报灯依然在亮。
/usr/lpp/diag*/bin/./usysfault -s normal这个办法也试过了，警报灯依然在亮。
errpt内容
# errpt
IDENTIFIER TIMESTAMP  T C RESOURCE_NAME  DESCRIPTION
F89FB899   0225150008 P O dumpcheck      The copy directory is too small.
2F3E09A4   0225111908 I H sysplanar0     REPAIR ACTION
8B88700A   0223164208 T H hdisk2         CACHE BATTERY CHARGE BELOW 87.5%
A6DF45AA   0223162808 I O RMCdaemon      The daemon is started.
1BA7DF4E   0223162808 P S SRC            SOFTWARE PROGRAM ERROR
BA431EB7   0223162808 P S SRC            SOFTWARE PROGRAM ERROR
BA431EB7   0223162808 P S SRC            SOFTWARE PROGRAM ERROR
EC0BCCD4   0223162708 T H ent1           ETHERNET DOWN
2BFA76F6   0222192008 T S SYSPROC        SYSTEM SHUTDOWN BY USER
9DBCFDEE   0223162708 T O errdemon       ERROR LOGGING TURNED ON
192AC071   0222191808 T O errdemon       ERROR LOGGING TURNED OFF
8B88700A   0128212708 T H hdisk2         CACHE BATTERY CHARGE BELOW 87.5%
A6DF45AA   0128211408 I O RMCdaemon      The daemon is started.
1BA7DF4E   0128211408 P S SRC            SOFTWARE PROGRAM ERROR
BA431EB7   0128211408 P S SRC            SOFTWARE PROGRAM ERROR
BA431EB7   0128211408 P S SRC            SOFTWARE PROGRAM ERROR
EC0BCCD4   0128211308 T H ent1           ETHERNET DOWN
9DBCFDEE   0128211308 T O errdemon       ERROR LOGGING TURNED ON
8B88700A   1129145107 T H hdisk3         CACHE BATTERY CHARGE BELOW 87.5%
8B88700A   1129145007 T H hdisk2         CACHE BATTERY CHARGE BELOW 87.5%
其中，这里面有SOFTWARE PROGRAM ERROR报错信息，IBM硬件工程师说这个问题比较严重，让我们找负责软件的工程师并在解决这个软件问题后清除报警灯，结果软件工程师说AIX已经过保，无法提供服务。我晕，硬件没过保，软件过保，怎么区分的这么细啊。
其实，说了这么多，这是2个问题。
1。使用IBM工程师提供的办法无法清除报警灯。
2。SOFTWARE PROGRAM ERROR这个问题正在google上找资料看呢，好像和nfs有关。

[ 本帖最后由 jlttt 于 2008-2-25 19:40 编辑 ]

yanbing

电话里面沟通过了，简要回答一下，方便看帖的其他兄弟：
1。P5系列的机器关掉警告灯是通过HMC，上面使用的2种方法只适用于P4及更早的设备；
2。software program error错误每次伴随开机的时候出现，具体原因需要通过snap来确定，我等你的邮件。

在看过snap之后我会给你详细的当前设备存在问题的总结，你也可以放心，根据当前提供的信息来看，设备状态是亚健康，但并无性命之忧！

jlttt

非常感谢yanbing ,能有你这样的朋友是我的荣幸。我也会尽快提供snap，让更多人一起交流一起学习。

yuxiao_zhao

/var空间太小了 放不下dump咯
抱歉 之前做的都是p5 520 550之类的机器 ps都是2g左右的
还是按照版主的提示计算dump需要的空间吧

[ 本帖最后由 yuxiao_zhao 于 2008-2-27 12:47 编辑 ]

jlttt

谢谢～～

jlttt

yuxiao_zhao，我的PS是6144M，我这个文件系统/var才128M，按照你的意思我是要再扩6144M，我怎么觉得有点不靠谱啊。呵呵～～
希望各位兄弟给出合理的扩充大小，并说明原因。谢谢～
# lsps -a
Page Space      Physical Volume   Volume Group    Size %Used Active  Auto  Type
hd6             hdisk1            rootvg        6144MB     3   yes   yes    lv

yanbing

之前一直在忙，没有充足的时间来看snap，所以delay到现在。

除了电话里面提到的FC ARRAY盘阵的电池需要更换之外，我们把重点放在你所担心的software program error上。

这3条报错伴随每次的重启出现，ID分别是BA431EB7 两次和1BA7DF4E 一次。

BA431EB7是说rpc.statd重启失败并且进行再次尝试；

1BA7DF4E是说rpc.statd无法重启；

而这个问题与两个地方的配置有关：

1。检查/etc/hosts ,察看相关内容是否如下所写：

   127.0.0.1       loopback localhost      # loopback (lo0) name/address

2。检查/etc/netsvc.conf，察看是否有相关内容如下：

    hosts=local,bind4

3。确定上述内容正确的情况下，使用：

   startsrc -s rpc.statd来启动rpc.statd进程；

4。使用lssrc -g nfs检查结果，如果出现以下字样：
    rpc.statd is now active...那么意味以后重启也不会有任何报错了。

还是如前面的判断，这些软件问题不是致命因素，不用担心，相比而言，更加重要的是数据备份机制的建立与执行。