原标题:由重启引起的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