Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1984440
  • 博文数量: 176
  • 博客积分: 1857
  • 博客等级: 上尉
  • 技术积分: 2729
  • 用 户 组: 普通用户
  • 注册时间: 2012-04-14 22:55
个人简介

吾生有涯,而知无涯,适当止学.循序渐进,步步提升 Talk is cheap, show me the code.

文章分类

全部博文(176)

文章存档

2019年(1)

2018年(14)

2017年(20)

2016年(31)

2015年(15)

2014年(5)

2013年(10)

2012年(80)

分类: Oracle

2013-01-17 10:51:21

http://www.itpub.net/thread-2714-1-1.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

阅读(2871) | 评论(0) | 转发(0) |
0

上一篇:dmidecode详解

下一篇:undo表空间的bug

给主人留下些什么吧!~~