适用于:
Oracle Database - Enterprise Edition - 版本 11.2.0.1 到 11.2.0.2 [发行版 11.2]
本文档所含信息适用于所有平台
用途
这篇文档提供了诊断 11.2 集群节点驱逐问题的参考方法。对于 11.2 之前的集群节点驱逐问题，请参考 Note: 265769.1。
适用范围
受众范围是遇到了集群节点驱逐问题的 DBA 和技术支持工程师。
详细信息
节点驱逐概要
Oracle 集群在发现一些严重问题时会将一个或多个节点从集群中驱逐出去。这种严重问题包括节点没有网络心跳、节点没有磁盘心跳、服务器无响应或者有严重性能问题、或者 ocssd.bin 无响应。节点驱逐的目的是通过去除一些节点来维护整个节点的健康。
从 11.2.0.2 RAC (或者是 Exadata)，节点驱逐也许并不会真正重启主机。这称为 rebootless restart。这种情况下，我们会重启大部分的集群进程来确认是否可以解决这台节点的问题。
1.0 - 会导致重启的进程
OCSSD (aka CSS daemon) - 这个进程由 cssdagent 进程所启动。对于使用第三方集群件和没有第三方集群件的环境都有这个进程。OCSSD 的主要作用是节点间的健康监控以及数据库实例的发现。健康监控包括网络心跳和磁盘心跳（针对选举盘）。OCSSD 在收到客户端（比如数据库的 LMON 进程）的 member kill escalation 请求后，也可以发起节点驱逐。OCSSD 进程是一个以 Oracle 用户身份运行的、多线程的、运行级别较高的进程。
启动顺序: INIT --> init.ohasd --> ohasd --> ohasd.bin --> cssdagent --> ocssd --> ocssd.bin
CSSDAGENT - 这个进程由 OHASD 进程启动，CSSDAGENT 用于启动 OCSSD 进程，它可以监控节点 hang（类似于 oprocd），同时也监控 OCSSD 进程 hang（类似于 oclsomon ），而且还监控第三方集群件（类似于 vmon） 。这个进程是一个以 root 用户身份运行的、多线程的、运行级别较高的进程。
启动顺序: INIT --> init.ohasd --> ohasd --> ohasd.bin --> cssdagent
CSSDMONITOR - 这个进程也会监控节点 hang（类似于 oprocd），同时也监控 OCSSD 进程 hang（类似于 oclsomon ），而且还监控第三方集群件（类似于 vmon） 。这个进程是一个以 root 用户身份运行的、多线程的、运行级别较高的进程。
启动顺序: INIT --> init.ohasd --> ohasd --> ohasd.bin --> cssdmonitor
2.0 - 确认由哪个进程发起了重启
需要查看的重要的文件：
- Clusterware alert log in <GRID_HOME>/log/<nodename>
- The cssdagent log(s) in <GRID_HOME>/log/<nodename>/agent/ohasd/oracssdagent_root
- The cssdmonitor log(s) in <GRID_HOME>/log/<nodename>/agent/ohasd/oracssdmonitor_root
- The ocssd log(s) in <GRID_HOME>/log/<nodename>/cssd
- The lastgasp log(s) in /etc/oracle/lastgasp 或者 /var/opt/oracle/lastgasp
- IPD/OS 或者 OS Watcher data
- GRID home 的'opatch lsinventory -detail'的输出
- *Messages 文件:
* Messages 文件路径：
- Linux: /var/log/messages
- Sun: /var/adm/messages
- HP-UX: /var/adm/syslog/syslog.log
- IBM: /bin/errpt -a > messages.out
Document 1513912.1 - TFA Collector - Tool for Enhanced Diagnostic Gathering
在大部分情况下，11.2 集群驱逐时会在集群的 alert log 中记录有意义的诊断信息。通过这些信息，可以确认是哪个进程发起了重启。下面是集群的 alert log 的样例：
[ohasd(11243)]CRS-8013:reboot advisory message text: Rebooting after limit 28500 exceeded; disk timeout 27630, network timeout 28500, last heartbeat from CSSD at epoch seconds 1241543005.340, 4294967295 milliseconds ago based on invariant clock value of 93235653
这次驱逐是由于遇到了网络超时问题所导致。CSSD 进程退出后，CSSDAGENT 发起了重启。CSSDAGENT 是从 CSSD 的本地心跳相关的错误中获得了这些信息。
如果在被驱逐的节点的集群 alert log 中没有相关信息，请检查本节点的 lastgasp 日志，以及/或者其它节点的集群 alert log。
3.0 - 诊断 OCSSD 发起的驱逐
如果遇到了 OCSSD 发起的驱逐，请参考 3.1 章节列出的常见原因：
3.1 - OCSSD 驱逐的常见原因
- 节点间的网络失败或者延迟。在连续的30秒（默认值，由 CSS misscount 决定)心跳不通后，会导致节点驱逐。
- 无法读写 CSS 选举盘。如果一个节点无法完成对于大多数选举盘的磁盘心跳，节点会被驱逐。
- Member kill escalation。比如，数据库实例的 LMON 进程可能会请求 CSS 将一个实例从集群中驱逐。如果实例驱逐超时，会升级为节点驱逐。
- OCSSD进程发生错误或者hang，这种情况会由上面任何一种情况或者其它情况引起。
- Oracle bug.
3.2 - OCSSD 驱逐时需要收集和查看的文件
在章节 2.0 所列出的所有节点的所有文件，也许还需要更多信息。
由于选举盘问题造成的驱逐的样例：
CSS log:
2012-03-27 22:05:48.693: [ CSSD][1100548416]###################################
2012-03-27 22:05:48.693: [ CSSD][1100548416]clssscExit: CSSD aborting from thread clssnmvDiskPingMonitorThread
OS messages:
Mar 27 22:03:58 choldbr132p kernel: Error:Mpx:Symm 000190104720 vol 0c71 is dead.
Mar 27 22:03:58 choldbr132p kernel: Buffer I/O error on device sdbig, logical block 0
...
4.0 - 诊断 CSSDAGENT 或者 CSSDMONITOR 驱逐
如果遇到了 CSSDAGENT 或者 CSSDMONITOR 驱逐，请参考章节4.1列出的常见原因。
4.1 - CSSDAGENT 或者 CSSDMONITOR 驱逐的常见原因
- OS 调度问题。比如，OS 遇到了驱动、硬件问题或者主机负载太高 (CPU 100% 被使用)等问题,会导致 OS 调度异常。
- CSSD 的一个或多个线程 hang。
- Oracle bug.
4.2 - CSSDAGENT 或者 CSSDMONITOR 驱逐需要收集和查看的文件
章节 2.0 所列出的所有节点的所有文件，也许还需要更多信息。
参考
NOTE:1053147.1 - 11gR2 Clusterware and Grid Home - What You Need to Know
NOTE:736752.1 - Introducing Cluster Health Monitor (IPD/OS)
NOTE:1513912.1 - TFA Collector - Tool for Enhanced Diagnostic Gathering
NOTE:301137.1 - OSWatcher (Includes: [Video])
NOTE:265769.1 - Troubleshooting 10g and 11.1 Clusterware Reboots