由重启引起的Oracle RAC节点宕机分析及追根溯源.docx

? ? ? ? ? ? ? 由重启引起的Oracle RAC节点宕机分析及追根溯源 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  1背景说明 某省份的电信业务系统由于业务量较大，按地市划分部署在4套配置相同的RAC上，相同主机版本，相同的CRS和数据库版本。该系统已正常运行3年多，其间也有重启主机等正常维护操作。从4月24日 开始，这个系统的4套RAC的节点，一个接一个地宕机重启，但每次都不是同一个节点。整理的宕机情况列表如下： 系统???? 宕机时间 ----------------- xx1db01?? 04-24 xx1db02 xx2db01?? 07-30 xx2db02?? 07-23 xx3db01?? 08-19 xx3db02?? 07-27 xx4db01 xx4db02 这4套RAC是3年前安装的，平时运行非常稳定，基本没有问题，从4月份开始有节点宕机，并且在7，8月份宕机频率非常高。但有点比较奇怪，每次宕机都是不同的节点，没有相同的节点发生宕机。由于配置了业务隔离，所以RAC宕一个节点，对业务影响不大，但是如此大规模的节点宕机，肯定有一些共性的问题。 每次宕机基本为ocssd.bin进程出错，直接重启节点。ocssd.bin报错的日志基本为： clssscExit: CSSD signal 11 in thread GMClientListener 这4套RAC的配置如下： 主机版本：HP-UX B.11.31 U ia64 数据库CRS版本为：10.2.0.5.0（未打PSU） 数据库版本为：10.2.0.5.8（PSU号 安装了Veritas Storage Foundataion，使用VCS集群文件系统。 24月24日宕机分析过程 4月24日，xx1db01节点宕机，这是这套业务系统的第一次节点宕机。由于没有安装OSWatch工具，无法得知宕机时操作系统资源情况。 检查操作系统日志，没有发现报错信息。这可能是系统直接重启时，还没有来得及把内存中的信息刷到磁盘。检查数据库的alert日志，宕机重启时数据库实例没有异常信息。 检查ocssd.log，发现如下报错： clssscExit：CSSD signal 11 in thread这个报错以前没有碰见过。 对这个报错的相关解释：当RAC GM client监听线程在处理clsc_disc_orphans时，CSSD.LOG中会出现clsc_disc_orphans的信息，该函数在处理clsc_disc尝试断开连接时，负责获得和持有线程信息。存在BUG(Bug 9132429: LNX64-10205-CRS:NODE CRASH AFTER 5 MINUTES OF HANG/RESUME OCSSD.BIN。)可能导致多个session形成死锁，最终导致节点HANG住或被驱逐宕机。 MOS上的这个Bug 9132429是在Linux平台上，当前主机是HP-UX。请网络组检查心跳交换机，没有发现闪断或者其它异常。由于没有检查到有用的信息，认为这可能是ocssd.bin进程的偶然报错现象，暂时没法解释这个问题。 37月23日宕机分析过程 07月23日，xx2db02发生宕机，检查结果和4月23日一样，其它全部没有信息，只有ocssd.log日志信息如下：  经过确认，主机重启是由于ocssd的GMClientListener问题导致。由于未在主机上安装系统资源监控工具，没有有效的主机资源使用情况。在MOS上了开SR，SR回复可能是主机资源使用存在问题，但没有OSW的信息，他们给不出解释。 47月27日宕机分析过程 7月27日，xx3db02宕机，Oracle Support认为在ocssd.log中存在Authentication OSD error信息，可能是认证失败导致GMClientListener发生问题，进而cssd.bin进程宕掉。相关日志信息如下： 认证信息失败的原因，可能有以下几点： 1、节点间有防火墙 ? 【没有配置】 2、节点间有authentication tools ? 【未配置】 3、$ORA_CRS_HOME/crs/css目录权限发生改变 【未发生】 4、/oracle文件系统满 ? ? ? 【未满】 5、/tmp目录下的.oracle目录被删除 ? 【未删除】 6、节点间认证信息网络包发生问题 ? ? 【无证据】 而前两次宕机，没有Authentication OSD error的信息，所以没有直接证据表明Authentication OSD error造成了CSSD signal 11 in thread GMClientListener，Authentic