公司rac集群为双节点oracle11g的rac，操作系统为AIX6.1,突然断电重启了，再次查看集群状态，发现其中一个节点起不来。
经过系统工程师检查，发现重启后存储的光纤网络有十几秒左右的延时，于是手动启动crs，结果保crs-4000问题。以root用户执行./crsctl start crs仍然不行。
怀疑是asm有问题，在grid用户下asmcmd，结果发现连接到空实例，真是
ASM没有启动，于是直接在asmcmd里startup没有启动。但是半天也没有反应，于是进入asm实例：
sqlplus / as sysdba,直接报没有权限连接。难道是因为环境变量，使用export手动指定环境变量，结果和刚才一样，而且sqlplus / as sysasm也是同样的错误。
经过询问，有人建议应该输入用户名密码，应为在监听服务没有启动的情况下，不能直接用空用户名密码登陆。但是用户名密码有点忘了，把密码文件备份删除后，使用orapwd命令重建密码文件。重建后使用sqlplus username/password as sysdba的方式登陆成功，但不能启动。使用sqlplus username/password as sysasm的方式登陆，仍然报权限的错误。
怀疑是不是共享存储权限的问题，但经过查看，发现各共享存储的连接情况和权限与第二个节点的情况一样。又怀疑是不是停电导致存储出现故障，但第二个节点一切运行正常。难道是ocr盘的问题，查找到该节点最近的OCR备份，想要restore一下，发现restore不能执行。
又想到一个办法，在另一个节点通过srvctl命令启动asm,srvctl start asm -n 节点名，但仍然不能启动，报节点1上ora.asm服务没有启动。通过crsctl stat res -t -init 发现，ora.crsd,ora.asm，ora.diskmon,都没有启动。ora.evmd状态为intermediate。
经过查询研究，认为应该是crs没有启动的问题。晕了，crs没有启动是因为asm没有启动，asm启动不起来是因为crs没启动起来！这不是造成死循环了吗？再次用root 用户重启crs,这回是先关闭再重启，结果都报错。想要看一下crs的启动关闭日志，结果发现crsd.log里只有断电之前的日志，根本没有之后的任何记录。
最后通过查找ohasd里的日志（非常大量），终于在其中发现了问题。应该是网络sqlnet.ora文件出来问题，经过排查，发现节点1的sqlnet.ora文件中有一行auth认证，好像多了一个空格，去掉空格，重启crs，crs成功启动。接着启动asm，监听，数据库实例等等也都一切正常。
总结，忙活了很长时间才搞定，更本原因还是对oracle rac的体系架构和启动流程不熟悉。crs启动的时候会通过监听去读取asm中的信息，而监听sqlnet里有一行auth的意思为操作系统认证，让crs通过操作系统认证方式读取asm中信息，如果这个没有，那当然读取不到asm中信息也就无法启动，同时crsd.log里也不会有任何记录，因为oracle应该是通过ipc去读写log文件，但是sqlnet都没有通过也就不能对日志有任何操作。其实也可以把这一行去掉，以免下次造成同样的问题。
以上总结是个人愚见，不代表真实情况，可能是错误的，完全是根据这次事故进行的猜测！哈哈！
本文出自 “posad” 博客，请务必保留此出处http://4445027.blog.51cto.com/4435027/1741429
系统突然断电重启导致rac节点无法启动，crs-4000错误
原文地址：http://4445027.blog.51cto.com/4435027/1741429
