某个生产系统,早上业务全部无法办理
环境是HP-UNIX oracle 10g asm rac
1、查看smon进程,猜看数据库应该还没down
$ ps -ef | grep smon
oracle 3932 31303 0 8:29 pts/4 00:00:00 grep smon
oracle 12820 1 0 Oct29 ? 00:00:04 ora_smon_orcl
2、查看实例状态
$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.5.0 - Production on Wed Oct 29 8:30:24 2014
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
SQL> select status from gv$instance;
STATUS
------------
OPEN
OPEN
实例是OPEN的,查看监听,监听也是正常的
3、开始排查警告日志,出现以下报错 HPUX-ia64 Error: 28: No space left on device
Wed Oct 29 02:56:49 EAT 2014
Unexpected communication failure with ASM instance:
error 9945 (ORA-09945: Unable to initialize the audit trail file
HPUX-ia64 Error: 28: No space left on device
)
NOTE: ASMB process state dumped to trace file /oracle/admin/sb/bdump/dysb1_arc1_871.trc
Wed Oct 29 02:56:50 EAT 2014
Unexpected communication failure with ASM instance:
error 9945 (ORA-09945: Unable to initialize the audit trail file
HPUX-ia64 Error: 28: No space left on device
)
4、排查锁定文件系统查看时是/oracle目录用满了,怀疑可能有大量的trace文件造成文件系统被耗尽
# bdf
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol3 1048576 600640 444664 57% /
/dev/vg00/lvol1 1835008 304184 1518944 17% /stand
/dev/vg00/lvol8 8912896 3106696 5764024 35% /var
/dev/vg00/lvol7 10240000 2925352 7257528 29% /usr
/dev/vg00/lvol4 10485760 3618184 6815280 35% /tmp
/dev/vg00/lvol9 20971520 20971520 0 100% /oracle
/dev/vg00/lvol5 131072 5792 124312 4% /home
5、开始查找crs,rdbms中的trace文件,发现集群和数据库的日志并不大只有几十MB
6、想到trace文件也就是几MB大小,于是使用find(例:find /oracle -size +10240 -print) 查找大于2MB的文件,发现crs目录下的cdata/crs中有大量的以数字字符串命名的文件
于是进入到cddata,发现了状况3万个以数字命名的文件,而且文件生成有时间规律,于是string 以下里面的内容发现里面的文件都是一些关于集群和机器的内容,怀疑是ocr自动备份的文件
#ls -al
total 39540
drwxrwxr-x 2 root oinstall 51200 Oct 29 10:44 .
drwxrwxr-x 4 oracle oinstall 96 Sep 30 2013 ..
-rw-r--r-- 1 root root 4145152 Oct 29 10:28 36156006
...........
.......省略
.....
-rw-r--r-- 1 oracle root 4145152 Oct 29 10:28 36156006
-rw-r--r-- 1 oracle root 3317760 Oct 5 2013 backup00.ocr
-rw-r--r-- 1 oracle root 2547712 Oct 5 2013 backup01.ocr
-rw-r--r-- 1 oracle root 2547712 Oct 5 2013 backup02.ocr
-rw-r--r-- 1 oracle root 2547712 Oct 4 2013 day.ocr
-rw-r--r-- 1 oracle root 2547712 Oct 5 2013 day_.ocr
-rw-r--r-- 1 oracle root 2539520 Sep 30 2013 week.ocr
为什么会产生数字字符串的文件呢,细心观察发现,以数字命名的文件属主、属组和时间与
*.ocr(包括所有的backup.ocr,day.ocr,week.ocr)的文件完全不同,正常情况下*.ocr的备份文件属主和属组用属于root,对比一下两个节点的
*.ocr文件的属组可以发现,出现了问题
节点 1
-rw-r--r-- 1 oracle root 4145152 Oct 29 10:28 36156006
-rw-r--r-- 1 oracle root 3317760 Oct 5 2013 backup00.ocr
-rw-r--r-- 1 oracle root 2547712 Oct 5 2013 backup01.ocr
-rw-r--r-- 1 oracle root 2547712 Oct 5 2013 backup02.ocr
-rw-r--r-- 1 oracle root 2547712 Oct 4 2013 day.ocr
-rw-r--r-- 1 oracle root 2547712 Oct 5 2013 day_.ocr
-rw-r--r-- 1 oracle root 2539520 Sep 30 2013 week.ocr
节点 2
-rw-r--r-- 1 oracle oinstall 3317760 Oct 5 2013 backup00.ocr
-rw-r--r-- 1 oracle oinstall 2547712 Oct 5 2013 backup01.ocr
-rw-r--r-- 1 oracle oinstall 2547712 Oct 5 2013 backup02.ocr
-rw-r--r-- 1 oracle oinstall 2547712 Oct 4 2013 day.ocr
-rw-r--r-- 1 oracle oinstall 2547712 Oct 5 2013 day_.ocr
-rw-r--r-- 1 oracle oinstall 2539520 Sep 30 2013 week.ocr
两个节点的*.ocr的备份文件权限完全不同,再看时间,2013年10月5日,也就是说,本套集群OCR的自动备份完全没有使用正常的备份文件,可能是属组的问题导致主节点产生以数字结尾的ocr非正常的备份文件
于是用以下的解决方案处理本次故障
01.修改两个节点 *.ocr备份文件的权限和属组
#chown root:root *.ocr
02.删除所有以数字命名的OCR备份文件
经过一天的观察,主节点不再产生36156006类似的ocr备份文件,由此确定是ocr备份文件的属主和属组的问题造成的cdata目录产生大量的ocr非标准的自动备份文件,属组的问题客户已经不确定当时是否有人修改过,或者RAC安装的时候就存在问题,本次故障是不是bug就没做深入研究了。
节点 1的ocr备份已经正常
-rw-r--r-- 1 root root 3317760 Oct 29 2014 backup00.ocr