导游

东方龙马技术工程师接到客户相关技术人员的电话,出现了无法访问相关交易系统的问题,远程登录检查或数据库日志等信息也无法查看。

根据当时情况,电话里基本无法判断确定具体原因,东方龙马工程师及时赶到现场后发现实为Oracle CRS hang住了,并迅速解决了问题。经过分析确认这次数据库故障是删除 /tmp/.oracle目录导致的。具体分析如下:

✎ 文 | 东方龙马(广州技术同事)

1、环境说明

OS操作系统:AIX

数据库版本:ORACLE 11.2.0.4

2、故障分析

(1)根据数据库报警日志确认问题

从上面的信息,我们看到,从2015年11月15日凌晨4:42 开始到库被重启前一直都要报无法连接ASM实例,导致了无法写日志写归档错误 。

(2)ASM 告警日志提示错误

从上面的信息看到,ASM也从2015年11月15日开始报错,结合之前无法写日志写归档的报错,我们基本可以确认数据库不正常是由于ASM问题引发的。

(3)grid 错误日志

根据GRID的报何错信息,我们基本可以推出:

1)GRID 日志记录,在11月15日凌晨2:00出现监听故障,2:27出现 CRS故障,2:00删除了 /tmp/.oracle的文件夹,GRID 马上就出现了监听器故障,后续有出现了CRS故障;

2)ORACLE数据库实例通过监听器连接ASM实例,在监听器故障之前已经建立的连接,当监听器故障时仍然可以正常使用,而数据库实例的启动归档日志进程进行归档时需要与ASM 实例建立新的连接,这个时候因为监听器已经故障了,导致数据库实例新建的连接无法连接到ASM实例,导致归档失败;

3)由于数据库实例有多个日志组,刚开始的时候只有一个日志组被写满无法归档,后来随着时间推移所有的日志组都被写满,但所有的日志组都没有完成归档,导致无日志组可用来写入 redo 条目,阻塞了应用的SQL。

删除 /tmp/.oracle目录导致故障的案例

该案来源于ORACLE metalink文档 ID 370605.1

Clusterware Intermittently Hangs And Commands Fail With CRS-184 as Network Socker Files in /tmp/.oracle or /var/tmp/.oracle Gets Deleted (文档 ID 370605.1)

APPLIES TO:

Oracle Database – Enterprise Edition – Version 10.1.0.2 to 11.1.0.7 [Release 10.1 to 11.1]

Information in this document applies to any platform.

SYMPTOMS

CRS hangs intermittently

crs_stat -t returns

CRS-0184: Cannot communicate with the CRS daemon.

node1 [crs]> crsctl check crsd

Cannot communicate with CRS

node1 [crs]> crsctl check css

Failure 1 contacting CSS daemon

ps -ef |grep d.bin will give you the pid of the process

for example

ps -ef |grep d.bin

oracle 19703 19281 0 Apr10 ? 00:01:03 /home/oracle/oracle/produc

oracle 19976 19950 0 Apr10 ? 00:06:47 /home/oracle/oracle/produc

root 19323 1 0 Apr10 ? 00:08:47 /home/oracle/oracle/produc

CAUSE

This is caused by a cron job that cleans up the /tmp directory which also removes the Oracle socket files in /tmp/.oracle

SOLUTION

Do not remove /tmp/.oracle or /var/tmp/.oracle or its files while Oracle Clusterware is up.

相关推荐