一个dg警告发现的硬件问题-白红宇

一个dg警告发现的硬件问题

阅读量：2445 次

发布时间：2019-05-10

本文共 2499 字，大约阅读时间需要 8 分钟。

今天收到一条报警短信，提示dg似乎出了点问题。信息的来源是从v$dataguard_status里面扫描得到的最新错误。

2015-09-15 22:06:19.0 Log Transport ServicesErrorError 12541 received logging on to the standby

2015-09-15 22:06:19.0 Log Transport ServicesErrorPING[ARC1]: Heartbeat failed to connect to standby 'stest11g'. Error is 12541.

看样子是心跳的检测失败了，看来主库和备库之间的网络可能出现了延迟之类的问题，在最大性能模式下，这个还是能够接受的，当时就没有在意。

等过了一会之后，自己想还是看看到底是怎么回事吧，毕竟别的库就没有保护这样的错误。

连接到备库之后，发现ssh连接是正常的，证明备库还是能够访问的，没有出现备库的宕机问题。

查看实例也存在，但是监听器给停掉了。自己也感觉挺奇怪，监听怎么会自动停掉呢。就手工启动，结果启动就报了下面的错误。

lsnrctl start listener

LSNRCTL for Linux: Version 11.2.0.4.0 - Production on 14-SEP-2015 23:27:38

Starting /DATA/app/oracle/product/11.2.0.4/bin/tnslsnr: please wait...

TNS-12547: TNS:lost contact

TNS-12560: TNS:protocol adapter error

TNS-00517: Lost contact

Linux Error: 32: Broken pipe

对于这个问题还是有些陌生，启动监听失败，启动其它的监听也是同样的错误，这个时候还是来看看日志里面是怎么描述的吧。

结果切换到监听日志的路径下，使用ll命令就得到了下面的错误。

$ ll log

ls: reading directory log: Input/output error

total 0

ls: reading directory .: Input/output error

这个错误又陌生了，查看资料显示应该是文件系统出了问题。

怎么验证呢，使用dmesg来做或者使用MegaCli都可以。

> dmesg|grep sd|less

sd 0:2:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT

sd 0:2:0:0: [sda] CDB: Write(10): 2a 00 13 f4 21 38 00 00 08 00

Buffer I/O error on device sda8, logical block 33423143

lost page write due to I/O error on sda8

end_request: I/O error, dev sda, sector 331257944

Buffer I/O error on device sda8, logical block 32984587

lost page write due to I/O error on sda8

end_request: I/O error, dev sda, sector 303472624

end_request: I/O error, dev sda, sector 628396920

JBD2: Detected IO errors while flushing file data on sda8-8

Aborting journal on device sda8-8.

EXT4-fs error (device sda8) in add_dirent_to_buf: Journal has aborted

EXT4-fs error (device sda8): ext4_journal_start_sb: Detected aborted journal

EXT4-fs (sda8): Remounting filesystem read-only

EXT4-fs error (device sda8) in ext4_reserve_inode_write: Journal has aborted

看来确实是文件系统出了问题，根源还是磁盘损坏导致的IO错误。

这种错误还是比较让人无奈的，只能稍后尝试更换硬盘或者切换到别的环境了，不过所幸的是问题发生在备库。

通过这个案例可以看出，对于dg中的警告信息也不要掉以轻心，很可能一个不经意的ora错误其实已经在警示重大的问题，如果及时关注，就为我们保证数据的安全提供了最快的补救措施。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-1800593/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/23718752/viewspace-1800593/

你可能感兴趣的文章

apple pencil_如何在iPad Pro的Apple Pencil上双击动作