rac集群cssd无法启动的解决方法.docx

rac集群cssd进程无法启动的解决方法dtqh双节点RAC集群其中一个节点的ocssd进程，不管通过什么手段都无法启动，通过手工去可以强行启动evmd、ocssd、crsd三个进程，但是过一段时间后除了CRSD进程是活着的外其它进程就全挂掉了，通过“ps aux | grep d.bin”命令查看只能看到CRSD进程了，查看操作系统日志/var/log/messages文件，其中确实有CSSD进程的启动信息，但是到最后就是异常终止了，文件中也只是提示详细信息去查看rac进程的日志。此问题折腾了一天多的时间从网上找各种资料，也尝试了各位网友说的方法试了无数的方法就是拿它没办法，因此下面主要是展出现这个问题时的所有日志信息，同时列出网上各位网友列举出来的方法，以及自己最终的解决办法。日志信息展示/u01/app/oracle/product/10.2.0/crs/log/dtsndb1目录中的alterdtsndb1.log日志文件的日志记录只输出如下图所的内容就结束了/u01/app/oracle/product/10.2.0/crs/log/dtsndb1/crsd/crsd.log日志文件在出现问题期间不管采取何种启动方式，得到的全时如下图的错误信息/u01/app/oracle/product/10.2.0/crs/log/dtsndb1/crsd/cssd/ocssd.log日志文件在出现问题期间不管采取何种启动方式，得到的全是如下图的错误信息，特别是第二张图片的内容占了整个日志输出的大部分/u01/app/oracle/product/10.2.0/crs/log/dtsndb1/crsd/cssd/oclsomon目录下的所有日志文件在出现问题期间得到的全是如下图的内容/u01/app/oracle/product/10.2.0/crs/log/dtsndb1/evmd/evmd.log日志文件在出现问题期间得到的全是如下图的内容首先要排除以下情况1、 保证节点间的心跳线通畅，节点之间互拼一段时间，确保拼的这段时间内数据包丢失率接近于02、 确保所有节点的防火墙都已关闭，使用“service iptables status”命令查看3、 检查所有节点的/etc/oracle/ocr.loc文件确保OCR磁盘应用正确，如下图所示客户OCR注册信息用的磁盘经确认没问题4、 经确认客户现场正常启动节点的表决磁盘没有什么问题5、 确认所有节点的共享磁盘设备权限是否正确如ocr、votedisk、数据文件磁盘设备的权限都正常，保证问题节点与正常节点的认到的磁盘设备及权限都一致；测试ocr及votedisk用到的磁盘读写是否正常6、 确保问题节点的/tmp/和/var/tmp/目录权限正确，正常情况下这两个目录的权限应该是这样的，如果权限不对的话RAC在启动的时候无法往这两个目录中写入相关信息，会影响css正常启动，因为启动脚本“/etc/init.d/init.cssd”中的变量CRSCTLOUT引用了此目录7、 在启动RAC的时候确保/tmp/.oracle、/var/tmp/.oracle、$CRS_HOME/log/sid/文件夹权限正确，/etc/init.d/init.cssd启动不管失败成功都会往此文件夹中输出日志信息，如果权限不对日志信息无法正常写入那么CSS启动就会有故障。以下是正常启动后的一些输出文件，重启RAC或者系统之前将此(/tmp/.oracle和/var/tmp/.oracle)目录中的所有文件全部删除，否则也有可能会引起CSSD无法正常启动8、 检查/etc/sysctl.conf文件添加如下两个参数9、 检查本地磁盘的可用空间是否已满，如果磁盘可用空间不足那必然也会导致CSSD无法正常启动的所有以上的方法及问题点都经检查没问题，后来实在没招了就直接运行了此脚本“/u01/app/oracle/product/crs/root.sh”，让它重新生成相关启动脚本及rac相关注册信息，然后神奇的是客户的rac都正常了，连续重启都能正常启动，rac相关的所有日志信息全部进行排查都提示rac启动正常，估计是客户系统中rac相关的文件被他们误损坏了。参考文献/200906/crs-cannot-start.htmlhttp: