RAC的故障定位
比单节点数据库更复杂
– 相关的进程更多
– 日志的存储位置更多
– 日志的信息量更大
– 故障更复杂
RAC的核心进程，cssd,crsd。这两个进程出现问题，那么RAC就宕了。RAC比单实例数据库进程要复杂的多。
RAC日志存放的位置也多，种类也多，相对于单实例。对于单实例数据库，所有的关于数据库的信息几乎都放在alter日志文件里面，包括数据库的故障，实例级别和数据库级别故障。下面就是单实例出现故障时候只需要查询的日志。
[oracle@RAC1 trace]$ pwd
/u01/app/oracle/diag/rdbms/oradb/oradb1/trace
[oracle@RAC1 trace]$ tail -100f alert_oradb1.log
从日志开始
操作系统日志
– windows ---日志管理器
– linux--/var/log/messages
RAC出现故障的时候可以最开始去读系统的日志。如果RAC启动不了系统日志就可以看到信息。
[root@RAC1 ~]# tail -5f /var/log/messages
Jun 24 21:06:55 rac1 kernel: [Oracle ACFS] DLM hash size 62500
Jun 24 21:06:55 rac1 kernel: ACFSK-0037: Module load succeeded. Build information: (LOW DEBUG) USM_11.2.0.4.0_LINUX.X64_130707 2013/07/07 22:39:19
Jun 24 21:06:57 rac1 kernel: OKSK-00010: Persistent OKS log opened at /u01/app/11.2.0/grid/log/rac1/acfs/kernel/acfs.log.0.
Jun 24 21:07:57 rac1 ntpd[1692]: Listening on interface #9 eth0:1, 192.168.56.203#123 Enabled
Jun 24 21:07:57 rac1 ntpd[1692]: Listening on interface #10 eth0:2, 192.168.56.21#123 Enabled
可以参考一下这篇诊断案例：点击打开链接
集群日志
11g下面切换到grid用户，到$ORACLE_HOME/log下面
[grid@RAC1 log]$ cd $ORACLE_HOME/log
[grid@RAC1 log]$ ls
crs diag rac1
[grid@RAC1 log]$ cd rac1/
[grid@RAC1 rac1]$ ls
acfs acfsreplroot agent crflogd cssd
acfslog acfssec alertrac1.log crfmond ctssd evmd
acfsrepl admin client crsd
要查看进程的日志就切换到相对应目录下面找相对应日志
[grid@RAC1 rac1]$ cd cssd/
[grid@RAC1 cssd]$ ls
core.2377 cssdOUT.log ocssd.log
[grid@RAC1 cssd]$ tail -10f ocssd.log
2018-06-24 21:31:02.117: [ CSSD][1890703104]clssnmSendingThread: sending status msg to all nodes
2018-06-24 21:31:02.117: [ CSSD][1890703104]clssnmSendingThread: sent 5 status msgs to all nodes
.............................................................
总结下日志文件及其路径
oracle 下的alert日志$ORACLE_BASE/diag/rdbms/orcl/orcl1/trace/alertorcl1.log
grid 下的 alert 日志 $ORACLE_HOME/log/rac1/alertrac1.log
css的日志$ORACLE_HOME/log/rac1/cssd/cssd.log ocssd.log
crs的日志$ORACLE_HOME/log/rac1/crsd/crsd.log
ohas的日志$ORACLE_HOME/log/rac1/ohasd/ohasd.log
evm的日志$ORACLE_HOME/log/rac1/evmd/evmd.log