一个使用ASM的单机数据库，重启后发现ASM起不来，报错说无法跟CSSD通信。CSSD应该是系统启动的时候自动启动的，LINUX系统，启动的脚本 就写在/etc/inittab文件最后的，查查后台的/var/log/messages，发现有报错信息： Cluster Ready Services waiting on dependencies. Diagnostics in /tmp/crsctl.16546，这个错误太熟悉了，捣鼓RAC的时候碰到很多次，无非就是设备找不到啦、权限不对啦等等，而且更详细的信息一般都在 /tmp/crsctl.16546里面，明确告诉你是什么问题。于是查看/tmp/crsctl.16546文件，发现居然是空的！这下傻眼了，再次重 启主机，还是相同问题，报错的TRACE文件依然是空的。手工把/etc/inittab中的CSSD启动的脚本拷过来执行，还这样，这抓瞎了，啥日志都 没有，没地方下手了。[@more@]
根据RAC上的经验，先去看看CSSD的日志吧。摸索到$ORACLE_HOME/log/hostname/cssd下面，果然发现了跟RAC类似的ocssd.log，打开看看，里面全部是clssnmPollingThread: node dataguard (0) missed(2) checkin(s)类似的信息，没有任何错误的日志。

想到了CRSCTL命令，用这个命令手工去启动下看看，结果发现命令根本无法运行，报错：
error while loading shared libraries: libclntsh.so.10.1: cannot open shared object file: No such file or directory
文件不存在，晕死，不会是文件不小心被删除了吧？虽然很怀疑，不过还是去find了一把，找到了两个文件，分别位于$ORACLE_HOME/lib和$ORACLE_HOME/lib目录。怀疑文件被破坏？或者因为文件权限不对？登陆另一个单节点的使用ASM的库，检查这两个文件，大小和权限完全相同。还是不放心，把另一个好的库的文件拷到这边覆盖，结果还是报相同的错误，看来不是文件的问题了。

GOOGLE来GOOGLE去，基本上都是说环境变量有问题，LD_LIBRARY_PATH设置不对，没有把lib下面的库文件引入到环境变量中，仔细检查，发现明明是引入了，而且其他命令都是正常的。后来怀疑难道是CRSCTL命令挂了？把整个库全部RELINK ALL了一把，还是不行。不过这时候离答案已经很近了。。。

中间还检查过CSSD启动的脚本中的LD_LIBRARY_PATH的引用，都是对的。一直以为CRSCTL是一个命令，结果无意中发现它居然是一个脚本，打开这个脚本搜索LD_LIBRARY_PATH相关的地方，果然发现了问题，其中的一个LD_LIBRARY_PATH手工改动过，这才想起来貌似N久之前花了很大力气找到这里修改了这个脚本，可现在怎么也想不起来当时为啥那么改了。把变量改回来，重试CRSCTL命令发现已经好了。直接REBOOT主机，起来后发现CSSD也顺利起来了，ASM也能正常起来了。

从这个问题可以得到一个结论：对于重要系统的任何修改都要有文档记录，而且方便查找。

死，也要死个明白。