鲁达
导读
东方龙马技术工程师接到客户相关技术人员电话反映相关的交易系统出现有表无法访问的问题，同时，也无法远程登录检查，也看不到数据库的日志等信息。根据当时情况，电话里基本无法判断确定具体原因，东方龙马工程师及时赶到现场后发现实为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.