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