网上查了一下，大概有如下几种说法：
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
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:
2. Locate the ons.config file in the 10g(rdbms) home and rename it to something else.
For example:
The listener needs to be restarted after these changes.
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.
--end--
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
检查时会发现系统上存在两个监听器进程，其中一个是另外一个的子进程。
检查监听 ps -ef | grep tnslsnr
KILL掉一个子进程，恢复正常
在Metalink上可以找到相关问题的很多解释，这个问题被最终确认为一个BUG，BUG号为：4518443
Oracle称在较大压力下，监听进程可能出现间歇性停止服务，此时Oracle会spaw出另外一个监听进程，进而导致两个监听进程互相影响的故障。