在RAC中的节点常常因为故障切换后无法恢复到正常状态。

     1.Listener is not running on node: rac1

   #crs_stat -t

   #srvctl status  nodeapps -n rac1   --查看节点1上的服务状态

    如果出现Listener is not running on node :rac1

    通常如果Listener is not running ,GSD服务也肯定无法启动，其是依赖listener

    2. lsnrctl status rac1

   进一步查看lsnrctl 的状态得到结果是

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1)))

TNS-12541: TNS:no listener

TNS-12560: TNS:protocol adapter error

  TNS-00511: No listener

    Linux :connection is refused 1

 初步可以断定是 Listener服务没有启动，启动该服务。

   3.在crs_start 命令

    crs_start  命令是无法启动一个处于unkown状态的服务的，

  这时应该 先使用crs_stop 命令停掉服务，再使用crs_start来启动。

   4.一次启动完成后使用crs_stat -t 查看 所有的服务是否处于完好online状态。

 

补充：有很多DBA再碰到故障时第一时间使用 crs_start all 来启动服务，这种思路无助于我们定位问题和解决问题，不推荐，现补充几个较常见的维护命令。

1.检查CRS的核心进程 CSSD,CRSD,EVM

rac1->crsctl check crs

rac2->crsctl check crs

2.查看各个节点的监听器的名称

$ crs_stat | grep lsnrNAME=ora.node1.LISTENER_NODE1.lsnrNAME=ora.node2.LISTENER_NODE2.lsnr