单位有一台ibm的powerPC,装的是for powerPC的linux,最近报警灯总亮,不知道该怎么排查问题

单位有一台ibm的powerPC,装的是for powerPC的linux,最近报警灯总亮,不知道该怎么排查问题,第1张

可以查看一下几个日志文件,是否有报错信息的记录:

1、/var/log/messages

这是linux的主要日志文件,很多错误信息都输出到这里;

2、dmesg

显示硬件信息

3、mail信息

查看root用户的mail信息,是否有关于错误的提示;

4、/var/log/boot.log

显示系统启动脚本的输出信息。此文件一般在重启机器后的一定时间内,就会被清空了。

5、到主机控制台,看看控制台屏幕上是否有错误信息输出

此外,PowerPC黄灯报警,一般都是硬件故障或是机房环境所致。

希望此帖能够对你有所帮助。

【ASM数据恢复】ORA-15196 invalid ASM block header [kfc.c] [check_kfbh]错误解析

ORA-15196: invalid ASM block header [kfc.c] [check_kfbh] [325] [2147483650] [2170461157 != 2170461165]

是当ASM读取到无效的asm block header时的报错,相关的BUG NOTE如下:

check_kfbh的存在时为了检验块的一致性 ,会对整个块做一个32 bit xor 来对比现有check_kfbh,有点象block的checksum

The field check_kfbh is adjusted to ensure that a 32 bit xor of the whole block will be zero. Check values are always calculated before writing a

block to disk, but may not be accurate for a block in the buffer cache. In this example the check value is “8A 8B D0 AE” but since this is little

endian the actual value is “0xAED08B8A

对于该问题 建议:

1、首先要检查 OS是否存在IO丢失的问题,例如 AIX上执行 errpt ,Linux查看os log 和dmesg

2、 检查RAC的多个节点上存储设备名是否一致

3、 考虑执行 ' alter diskgroup check norepair'来检查ASM diskgroup

4、11.2中如果遇到上述情况会自动使用amdu工具dump ASM disk其trace一般在ASM对应的user dump下 ,如NOTE: AMDU dump of disk group MAC created at /oracle/diag/asm/+asm/+ASM3/trace, 整个AMDU trace里包含了很有用的信息,如果存在大量的AMDU-00209: Corrupt block found: Disk N0072 AU [26127] block [94] type [0]信息,和看到 Corrupt metadata blocks: 320 大量损坏的元数据块, 则说明该问题一般是由于 OS层或者磁盘/存储硬件层引起的,因为不太可能有ASM的bug 会造成这么大量的损坏, 解释成丢失更新 Lost Update也不合理

5、实际上如果你和我一样检阅过上面全部的BUG Note,你会发现没有个BUG note是最终定位为real bug的,这些SR/Bug Note最终要么不了了之,要么查出来确实是OS或者硬盘/存储有问题;所以对于这个问题提交SR的效率很低, 往往找OS和存储厂商一起检查更有效率

6、如果你真的遇到了该问题,那么如果坏掉的元数据块(metadata block)比较少的话,可以请相关的ASM专家手工帮你修复,具体也可以找ASKMACLEAN专业ORACLE 数据库修复团队成员帮您恢复。切记不要在无备份ASM header的情况下 *** 作,否则可能丢失恢复数据的最后一线希望。

windows系统:

通过‘任务管理器’>‘性能’ 即可监控虚拟机性能。

linux系统:

top:linux自带的实时监控工具,可监控系统性能。

sar:监控系统cpu性能

vmstat:监控cpu、磁盘

iostat:检测I/O设备性能

svmon:查看系统内存使用情况

另外可用nagios等一些开源监控软件来监控系统性能

aix系统:

topas:aix系统自带的实施监控工具(类似linux的top)

sar 1 3:监控cpu,和linux相比需要带上参数。(每秒刷新1次,共刷新3次)

errpt还可查看系统错误日志。

其他监控命令基本和linux一样


欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/yw/7097993.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-01
下一篇 2023-04-01

发表评论

登录后才能评论

评论列表(0条)

保存