lsnrctl hang住的问题以及解决方法

http://www.itpub.net/thread-2714-1-1.html

http://yumianfeilong.com/html/2010/09/15/470.html

其中介绍hang住问题的metaling文章如下：

3. Why the listener hangs.

This is a very important section for hung listeners. There are many cases where a rouge client may be causing the listener to hang. This scenario happens almost all of the time. When a client sends it’s connect data, if the total packet length is greater than 230 bytes, SQL*Net on the client will break up the packet into 2 pieces: a 50 byte connect packet, and a second packet continuing connect data. When a client sends the connect request to a TNS listener, a procedure called nsanswer() is invoked. When nsanswer() gets the connect packet, the listener will wait in a blocking mode for the connect data to arrive. Usually, the connect data arrives after the 50 byte connect packet. The question is, what happens to the listener if the connect data never arrives? As an example, imagine that at connect time with a Windows 95 application, the application GPFs, but just before the GPF, a 50 byte connect packet left the client. The listener s nsanswer() is invoked, and is now waiting for connect data. Connect data never arrives because of the GPF on the client. What happens to the listener? The listener is “hung” in a read state forever waiting for connect data. Theoretically, this can be fixed by setting connect_timeout_listener to a value greater than 0 in the listener.ora file. After connect_timeout_listener seconds have passed, the listener should completely drop the connection request, and be available to accept a new connection. As a test, you can TELNET to a listener which will invoke nsanswer(). Since TELNET does not send any TNS connect information, both the TELNET and the listener will not return to a normal status until connect_timeout_listener has been reached. If connect_timeout_listener is set to 0, the listener will hang forever. If the TNS connect data is less that 230 bytes, then only one single connect packet will be sent to the listener. In this case, the listener should not hang because the listener will not block waiting for more connect data. To make the TNS connect data less than 230 bytes, you will need to remove items from the tnsnames.ora file such as ADDRESS_LIST, COMMUNITY, lengthy fully qualified host names, etc. Most of the listener hang situations are fixed on 9i.There are situations when the listener hang can be caused by OS or specific environment settings. The bottom line: Upgrade hung listeners to a a latest version listener if possible.

解决方法思路如下：

tnsping listener

if return code is

then do nothing

and tnsping the listener later.

else

do a PS and grep for tnslsnr PID

kill -9 listener_pid

lsnrctl start

resume cron job end.

个人总结后的方法：

1.查看网络情况： netstat -an | grep 1521

2.看是否能连接： lsnrctl status

3.找出tnslsnr pid

ps -ef | grep -v grep |grep tnslsnr | awk '{print $2}

4.kill掉

tnslsnr pid kill -9 listener_pid

5.重启

lsnrctl lsnrctl start