RAC 启动过程出错各种实战

CRS启动4405错误

天津仓储一个项目今天现场DBA关了RAC,但启动时报错

Su �C 
#cd /u01/app/grid/product/11.2.0/bin
#./crsctl start cluster �Cn tjccdb1 tjccdb2
遇到crs-4405错误,

wKioL1MIylTx7Rp4AAHhoiBhCGE589.jpg

同时用如下命令 

crsctl check crs   crsctl check has 系统卡住了,命令不出来结果
这时连甚至连ps -ef的命令都挂起,halt命令无法停机。经询问现场人员,当时
停集群报错,重启服务器后再启动CRS就报这个错,查看CSSD日志,仲裁信息的混乱,在两个节点crs都是启动状态下,两个节点的crs进程都挂起。
 
 
 
用如下步骤来解决:
断电机器,1#节点启动后,crs与db启动正常,关闭db与crs,再启动2#节点,crs与db启动正常,然后启动1#节点的crs和db,恢复正常。

 

网上哥们遇到双节点RAC数据库,只能启动一个节点,无论哪个节点先启动,另外一个节点就无法正常启动了  具体就是使用hacmp 5管理共享磁盘,无法启动的表现就是可以mount,alter database open就hang在那不动

解决思路:

出现该问题前,客户进行了一下数据转换的操作,中间等待长时间无反应,所以最后选择重启数据库,然后hang住很长时间,然后shutdown abort关闭数据库,然后再启动就出现上述问题!

到达现场,开始尝试启动无法启动的数据库,发现就是hang在alter database open的过程,如果不做任何操作,就一直hang在这个过程不动,观察系统负载,没有任何变动,如果这时候关闭第一个启动的节点,第二个启动的节点就能完成正常启动。这个过程数据库中在做什么呢?

判断来判断去,在metalink中也搜索半天,发现有个两个bug可能导致这个问题,但是打相应patch后依然如故!两个patch分别为p5106909和p5190596,感兴趣可以去参考下!

分析从故障开始的日志,发现在alert日志中有Waiting for clusterware split-brain resolution,中文就是脑裂,怀疑网络存在问题,但是使用ping命令ping心跳地址,正常!!!

系统中errpt有:

4507DE58   0507180209 I H ent2           ETHERNET NETWORK RECOVERY MODE
DED8E752   0507180209 T H ent2           ETHERNET DOWN
4507DE58   0507180209 I H ent5          ETHERNET NETWORK RECOVERY MODE
DED8E752   0507180209 T H ent5           ETHERNET DOWN
系统工程师说是网卡模式问题,应该没什么影响!(我就相信了据说是IBM的工程师,结果后来……唉!)

所以下面我就又开始折腾这个数据库啊,各种方法尝试,折腾一天,没有什么眉目,回去休息,明天继续吧!

结果第二天一来,客户就告诉我,应用的工程师,把两个数据库节点都给起来了,方法就是:启动第二个节点的时候,在第一个节点执行命令:alter system flush buffer_cache;就是清空第一个启动节点的buffer cache,然后第二个节点就能正常启动了!不知道他是怎么想到的,但是这就说明,其实第二个节点启动时候hang在了同步buffer cache的过程了,清除了第一个节点buffer cache就好了!具体猜想应该是数据字典!

虽然是都启动了,但是这种方式绝对不是解决办法,因为如果再有需要同步cache的操作,数据库还是会出现问题,结果运行了大约1个多小时,数据库果然出现问题:又出现脑裂,日志如下:

Thu May  7 09:19:11 2009
IPC Send timeout detected. Receiver ospid 160682
Thu May  7 09:19:11 2009
Errors in file /oracle/app/admin/orcl/bdump/orcl2_lms0_160682.trc:
Thu May  7 09:19:12 2009
Trace dumping is performing id=[cdmp_20090507091857]
Thu May  7 09:20:52 2009
Waiting for clusterware split-brain resolution
Thu May  7 09:25:55 2009
Errors in file /oracle/app/admin/orcl/bdump/orcl2_lmon_114856.trc:
ORA-00600: Message 600 not found; No message file for product=RDBMS, facility=ORA; arguments: [kjxgrdecidemem1]
Thu May  7 09:25:56 2009
Trace dumping is performing id=[cdmp_20090507092556]
Thu May  7 09:25:56 2009
Errors in file /oracle/app/admin/orcl/bdump/orcl2_lmon_114856.trc:
ORA-00600: Message 600 not found; No message file for product=RDBMS, facility=ORA; arguments: [kjxgrdecidemem1]
Thu May  7 09:25:56 2009
LMON: terminating instance due to error 481
Instance terminated by LMON, pid = 114856

明天还要去客户现场,又是9点到,还在南城,睡觉~

未完待续~~~~~~~~~~

还是继续写完吧~~~~~~~

后来经过检查,发现在netstat -s查看时发现有丢包现象,但是还是没有引起我的足够注意,再后来我实在是找不到原因,只好建议客户从网络和系统方面都排查!正好这时候客户请来另一家的工程师解决,我觉得人家在两个方面做得比我好:

1、先是去看了现场硬件配置环境(我就没去看过)

2、从可能的原因一一排查(我就一直专注于找到比较可信的原因)

可能是在一家公司呆久了,也可能是经常一个人解决问题,行成了自己的固定思维模式,总之,最后是我没有找到比较可行的解决方法,而另一家公司的工程师建议客户排除网络(心跳线等原因)、系统等方面,再想起他方法,结果心跳线一换就ok啦~~~~~~~

 

 

点评:其实从Instance terminated by LMON, pid = 114856 这里显示LMON----来终止实例,LMON就是各个实例的LMON进程会定期通信,以检查集群中各个节点的健康状况,当某个节点出现故障时,负责集群重构、GRD恢复等操作,它提供的服务叫做Cluster Group Services。从这里看这个实例LMON通信不正常, 这个表明是心跳问题。

 

 

惜纷飞的例子:

solaris 11.2 两节点rac无法启动,让我帮忙看下。通过分析是因为sga_target参数设置不合理导致asm无法正常启动
GI无法正常启动

grid@zwq-rpt1:~$crsctl status resource -t 

CRS-4535: Cannot communicate with Cluster Ready Services 

CRS-4000: Command Status failed, or completed with errors. 

grid@zwq-rpt1:~$crsctl status resource -t -init 

-------------------------------------------------------------------------------- 

NAME           TARGET  STATE        SERVER                   STATE_DETAILS        

-------------------------------------------------------------------------------- 

Cluster Resources 

-------------------------------------------------------------------------------- 

ora.asm 

      1        ONLINE  OFFLINE                               Instance Shutdown    

ora.cluster_interconnect.haip 

      1        ONLINE  ONLINE       zwq-rpt1                                      

ora.crf 

      1        ONLINE  ONLINE       zwq-rpt1                                      

ora.crsd 

      1        ONLINE  OFFLINE                                                    

ora.cssd 

      1        ONLINE  ONLINE       zwq-rpt1                                      

ora.cssdmonitor 

      1        ONLINE  ONLINE       zwq-rpt1                                      

ora.ctssd 

      1        ONLINE  ONLINE       zwq-rpt1                 ACTIVE:0             

ora.diskmon 

      1        OFFLINE OFFLINE                                                    

ora.evmd 

      1        ONLINE  INTERMEDIATE zwq-rpt1                                      

ora.gipcd 

      1        ONLINE  ONLINE       zwq-rpt1                                      

ora.gpnpd 

      1        ONLINE  ONLINE       zwq-rpt1                                      

ora.mdnsd 

      1        ONLINE  ONLINE       zwq-rpt1

这时查看CSSD,发现

[/export/home/app/grid/bin/oraagent.bin(1348)]CRS-5019:All OCR locations are on ASM disk groups[CRSDG], and none of these disk groupsare mounted. Details are at "(:CLSN00100:)"in"/export/home/app/grid/log/zwq-rpt1/agent/ohasd/oraagent_grid/oraagent_grid.log". 

ASM都起不来了,OCR和VOTING DISK 肯定加载不起来,不报错才怪。继续看ASM日志

/export/home/app/oracle/diag/asm/+asm/+ASM1/trace/+ASM1_ora_1732.trc  (incident=291449): 

ORA-04031: unable to allocate 32 bytes of shared memory ("shared pool","unknown object","KGLH0^34f764db","kglHeapInitialize:temp") 

这时报share pool 不能allocate,进到pfile查看

ystem parameters with non-default values: 

  sga_max_size             = 2G 

  large_pool_size          = 16M 

  instance_type            = "asm"

  sga_target               = 0 

这里不能自动管理,而有没有设置share pool,这时只需要设置,再重启CRS即可。

 

 

你可能感兴趣的:(RAC,CRS,4405错误)