oracle rac实例驱逐,如果有人问你11g RAC如何实现驱逐与重启，请看这篇文章！

rac 在实施过程中已经几乎成为标配了，最近接触了几个rac节点重启的案例，做一个总结与整理。节点驱逐是我们日志工作中经常遇到的一个问题，有时候是节点重起了，有时候是集群重起了，有时候只是数据库实例重启了。当这类问题出现时，首先远程或者跑到客户现场分析故障，总有这样那样的原因，最近抽空在mentalink和google上收集了很多资料，做了如下总结，另外因为涉及的东西太多了，有的地方直接用英语原文，如有翻译或者总结不正确或者详细者，请朋友们原谅并欢迎指正。

节点驱逐发生在严重的情况下，可能是节点之前没有网络心跳、磁盘心跳、节点hang住没有反映、CSSD进程hang住，驱逐的目的是踢除坏的节点从而保证集群的健康。 从11.2.0.2开始，节点驱逐一开始并不重起操作系统，采用的是robustless重起，一开始只试着去自重起crs, 只有当crs不能成功自重起时，才会试着去重起节点。

当驱逐或者重启发生了时，要想知道为什么会重启，首先要知道哪些东西会引起驱逐或者重启，什么东西触发了驱逐与重启。下面我们就讲讲几个相关的几个进程。

【负责驱逐或重起节点的进程】

▲OCSSD

由cssdagent进程触发，OCSSD进程的主要功能是节点健康状态检测与监控，以及实例发现(internode health monitoring and RDBMS instance endpoint discovery)，它监控的包括网络心跳和磁盘心跳。即当rac 节点之前出现网络故障或者磁盘心跳故障时，ocssd进程就会试着去发挥作用了。

OCSSD can also evict a node after escalation of a member kill from a client (such as a database LMON process).

OCSSD 还会引起节点驱逐与重启，当ossd进程试着去驱逐一个实例时，如果驱逐不成功时就会升级“member kill”到“node kill”从而引起节点驱逐与重启。

startup sequence: INIT --> init.ohasd --> ohasd --> ohasd.bin --> cssdagent --> ocssd --> ocssd.bin

▲CSSDAGENT

cssdagent进程，该进程由OHASD衍生的，负责spawn OCSSD进程，监控节点hang(调用oprocd 10g rac里面用的是这)和ocssd进程hang(oclsmon10g rac里面用的是这货)。当它发现ocssd进程hang住，长时间没有反映时，这可能是由ocssd进程本身引起的，也可能是由节点上其它进程占用大量资源引起的，或者是硬件资源引起的如主板或者cpu故障引起的操作系统调度出现问题了，还有可能是oracle bug。

startup sequence: INIT --> init.ohasd --> ohasd --> ohasd.bin --> cssdagent。

▲CSSDMONITOR

cssdmonitor进程，该进程同样监控节点(调用oprocd)hang和ocssd进程hang(通过oclsmon)，和cssdagent进程一样，有很高的优先级，在root用户下运行，原理同上。

【 检查日志等相关文件】

当问题发生了就得开始分析研究问题了，到底是什么引起了问题，这时候都会去检查日志文件，既然11g RAC，那得知道它的日志体系，因为日志是由进程写的，所以能了解11g rac上面的进程关系，请看下图：

那么它的日志体系是怎么样的呢，相应的日志结构(按树状图的层次)：

第一层

▪ OHASD 日志位于：$Grid_home/log//ohasd/ohasd.log

第二层(OHASD的agent)

第三层(资源)

第四层(CRSD的agent)

有了上述知识，知道了哪些进程会干“坏事”，也知道了他们干了“坏事”会在哪留下证据。所以当客户“报警”之后，需要做的就是收集相关日志文件。

▲收集相关日志文件

▪Clusterware alert log in

▪cssdagent log(s)

▪cssdmonitor log(s)

▪ocssd log(s)

▪Crsd logs

▪lastgasp log(s) in /etc/oracle/lastgasp or /var/opt/oracle/lastgasp

▪CHM or OS Watcher data

▪'opatch lsinventory -detail' output for the GRID home

▪操作系统日志文件: