TNS Listener Hang, New Child Listener Process Forked

最近几天客户有台数据库监听经常挂死，首先检查监听的状态

[wxwl01#/]ps -ef|grep lsnr
  oracle 16807 12990  0 11:24:19 ?         0:00 /home/bonc/oracle/OraHome_1/bin/tnslsnr hold -inherit
  oracle 12990     1  0 18:11:11 ?         2:22 /home/bonc/oracle/OraHome_1/bin/tnslsnr hold -inherit

有两个监听进程产生，并且一个是子进程，此时tnsping、lsnrctl status都挂死。怀疑是oracle的一个监听器bug，谁叫oracle bug这么多呢。metalink上一搜就出来了，bug 4518443  ，doc ID 340091.1，如下：

Applies to:

Oracle Net Services - Version: 10.1.0.3.0 to 10.2.0.2.0 - Release: 10.1 to 10.2
Information in this document applies to any platform.
All new connections via TNS listener hang, no errors reported

Checked for relevance on 05-FEB-2010.

Description

Intermittently the TNS listener hangs and new connections to the database are not possible.

Likelihood of Occurrence

The issue is that the TNS listener can hang under load if a second spawned listener process is not closed (remains persistent). Secondary listener processes are not unusual, depending on traffic as well as when the OS grep snapshot is taken. However, a persistent secondary process (longer than say 5 second) is not normal and may be a result of this referenced problem.

TNS listener can hang at any time and effect standalone or RAC systems

Possible Symptoms

Listener process can also consume high amount of CPU

Child TNS listener process is seen when doing a ps on the listener process, eg.:

$ ps -ef | grep tnslsnr 

ora10g 8909 1 0 Sep 15 ? 902:44 /u05/10GHOME/DBHOME/bin/tnslsnr sales -inherit 
ora10g 22685 8909 0 14:19:23 ? 0:00 /u05/10GHOME/DBHOME/bin/tnslsnr sales -inherit 

Killing the child process allows new connections to work until the problem reoccurs

Workaround or Resolution

Issue is fixed in 10.2.0.3 Patch Set
Oracle Support recommends patching to 10.2.0.4 as this the lastest release

- OR -

Apply Patch 4518443 for the problem (if a patch is available)

- OR -

As a workaround, two steps should be done:

1. The following parameter can be added to listener.ora

SUBSCRIBE_FOR_NODE_DOWN_EVENT_=OFF

Where should be replaced with the actual listener name configured in the LISTENER.ORA file. This parameter is to be placed by itself on an empty line / at the end of file.

For example, if the listener name is LISTENER (default), the parameter would be:

SUBSCRIBE_FOR_NODE_DOWN_EVENT_LISTENER=OFF

2. Locate the ons.config file in the 10g(rdbms) home and rename it to something else.
For example:
cd $ORACLE_HOME/opmn/conf
mv ons.config ons.config.orig

The listener needs to be restarted after these changes.

This will both prevent the listener from registering against ONS (Oracle Notification Services), which is the area affected by bug:4518443, as well as disable ONS itself. For more information on ONS, please refer to the specific Oracle documentation, for example, for 10.2, see the Oracle10g Release 2 Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide.

Please note, that adding the SUBSCRIBE_FOR_NODE_DOWN_EVENT_ to listener.ora file on RAC and disabling the ONS file, will mean that FAN (fast application notification) will not be possible. See Note 220970.1 RAC: Frequently Asked Questions for further information on FAN. Therefore, if you have a RAC configuration, then apply the patch and do not disable ONS or FAN.

Also, please note that this might happen with ANY 10g installation, whether it is RAC related or not, and whether there is an Oracle Application installation or not.

对于这个bug的解决方案，一种方法是打上此补丁，此方法需要重启数据库；

另一种方法是更改监听的配置，此方法不用重启数据库。我选择了后者，观察看看。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/11088128/viewspace-686907/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/11088128/viewspace-686907/