oracle19c集群重启,由重启引起的Oracle RAC节点宕机分析及追根溯源

原标题：由重启引起的Oracle RAC节点宕机分析及追根溯源

作者介绍

裴征峰，现就职于北京海天起点，二线专家成员，南京办事处负责人，OCP 10g、OCP 11g、OCM11g。超八年Oracle服务经验，擅长数据库故障诊断和性能调优。目前主要从事客户的现场维护、重大问题的解决、数据库性能分析、二线服务质量保证等工作。

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号：13923855)

安装了Veritas Storage Foundataion，使用VCS集群文件系统。

2

4月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/R