ANBOB™

前两天遇到个问题， 我不清楚之前的操作，当时的情况是LISTENER启动但是客户无法连接，是一套11GR2 的RAC 环境， CRSCTL CHECK CRS检查CRS 服务已无法通讯，当时也让他查询了crsd.bin 进程确认不存在了， 当时通知重启CRS便可以解决，但是后来通知客户端依旧有个节点无法连接，检查LISTNER 并没有注册任何SERVICE，而且当时也只监听在PUBLIC IP， 检查DB PARAMETER LOCAL_LISTENER 是绑定VIP， 了解监听动态原理都知道这种情况通过ALTER SYSTEM REGISTER ，手动注册也是无法注册到LISTENER中。再通过crsctl stat res -t 检查资源状态如下图：

显示listener资源INTERMEDIATE 在2节点，并且” Not all endpoints registered”  这个状态没有太关心，当时因时间紧迫干脆手动注册监听。不方便Search, 其实绕了个弯子。

修改节点2 TNSNAMES.ORA 把 vip, public 写一个记录， 修改当前instance 的LOCAL_PARALETER 参数到刚加的TNSNAME ALIAS ，进数据库 ALTER SYSTEM REGISTER; 监听上有了当前INSTANCE 的service, 不过当时还是只有public,这时客户说可以了，看来客户配置的应用数据库连接字符串中用的是public vip, 当时客户看的出太晚也急的着睡，CRS 的LISTENER资源就保留了那个状态。

回头查了一下那个问题，MOS中也有写Listener in INTERMEDIATE status with “Not All Endpoints Registered” (文档 ID 1454439.1)， 不再过多描述，猜测在CRS重启前就有人手动在DB ORACLE_HOME 使用lsnrctl start 启动监听。解决方法是stop 了DB home 的listener, 重启CRS 里的GI home 的LISTENER 资源：

 srvctl start listener -l listener

回头想想自己当时也有想到DB和GI 的listener的都启的可能，而且当时还在oracle db home 用lsnrctl status查看了监听当时是启动的，只是注意到用的是GI home里的listener.ora 文件就错误的认为了这是GI 启的监听， 当时如果ps -ef|grep lsnr进程也可以发现这个问题。

另个注意如果想静态注册LISTENER 在11G略有变动，因为11G 引入了endpoints_listener.

— 在这里记录一下 —