起因：

最近研发反应JDBC和PL/SQL工具连接过慢，昨天事情多懒得去管http://www/uc/myshow/blog/misc/gif/E___6724EN00SIGG.gifTNSconnection closed ORA-609错误处理" TITLE="[转载]TNS-12537 TNSconnection closed ORA-609错误处理" />

今早检查alter.log后发现报错

Fatal NI connect error 12637, connecting to:

 (LOCAL=NO)

  VERSION INFORMATION:

        TNS for Linux: Version 11.2.0.1.0 - Production

        Oracle Bequeath NT Protocol Adapter for Linux: Version 11.2.0.1.0 - Prod                                                                                                 uction

        TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.1.0 - Production

  Time: 23-APR-2013 11:05:10

  Tracing not turned on.

  Tns error struct:

    ns main err code: 12637

TNS-12637: Packet receive failed

    ns secondary err code: 12532

    nt main err code: 0

    nt secondary err code: 0

    nt OS err code: 0

opiodr aborting process unknown ospid (24234) as a result of ORA-609

Tue Apr 23 11:05:15 2013

故障分析

检查 listener 日志确认没有异常，在部分机器 TNSPING XXX 60 等进行尝试结果正常，无链接问题

明显感觉，只要第一次 tnsping 链接正常，之后的 jdbc 链接就正常；如果第一次不正常，之后的 jdbc 链接就容易返回超时的错误。

尝试重启 lsnrctl stop/start 和重新加载配置文件  lsnrctl reload 重新注册数据库实例，仍然无法解决超时错误。

tnsping xxxx N 的时候明显观察到：

OK (56730 msec)
OK (80 msec)
OK (80 msec)
OK (70 msec)
OK (70 msec)
OK (60 msec)
OK (47820 msec)
OK (70 msec)

同时 PING IP 的结果并没有出现延时，机器之前并未设置防火墙等，可以排除网络和防火墙问题。
在连续 TNSPING 的情况下，出现明显链接延时。

解决方案

方案一：（有效，但是由于是测试环境，所以影响层面未评估）

注释掉 /etc/resolve.conf 配置文件中对 DNS 的解析解决
[oracle@vcdog log]$ cat /etc/resolv.conf 
#nameserver 202.106.0.20

方案二：官方文档（效果不明显）

ORA-609 TNS-12537 and TNS-12547 in 11g Alert.log [ID 1116960.1] 

Cause

The ORA-609 error is thrown when a client connection of any kind failed to complete or aborted the connection process before the server process was completely spawned.

Very often, this connection abort is due to a timeout.  Beginning with 10gR2, a default value for inbound connect timeout has been set at 60 seconds.  This time limit is often inadequate for the entire connection process to complete.   

We have also discovered that the ORA-609 occurs frequently in installations where the database is monitored by DB Console and the Enterprise Manager agent (emagent).   After the DB Console is started and as a matter of routine, the emagent will repeatedly try to connect to the target instances.  We can see frequent emagent connections in the listener.log without error.  However, on occasion it may have failed to complete the connection process at the database so an ORA-609 is thrown.  The emagent will simply retry the connection and may be successful on the subsequent try.  (Provided there is no real fault occurring at the listener or database).  This temporary failure to connect will not be reported back to DB Console and there will be no indication, except for the ORA-609, that a fault occurred.

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Solution

It can be somewhat challenging  to determine the origin of the client that is causing the error. 

For that reason, we often recommend increasing the values for INBOUND_CONNECT_TIMEOUT at both listener and server side sqlnet.ora file as a preventive measure.  If the problem  is due to connection timeouts, an increase in the following parameters should eliminate or reduce the occurrence of the ORA-609s.

e.g.

Sqlnet.ora: SQLNET.INBOUND_CONNECT_TIMEOUT=180
Listener.ora: INBOUND_CONNECT_TIMEOUT_listener_name=120

These settings are in seconds.  Again, the default is 60.

If the issue persists and inbound connect does not have any effect, the following steps are intended to help locate  the client that may be causing the errors.

1)  Suppress the TNS errors in the alert.log by setting the following listener.ora file parameter: 

DIAG_ADR_ENABLED_listener_name=OFF

This will cause the TNS errors to be posted to the ORACLE_HOME/network/log/sqlnet.log file that is local to the database and may yield useful information about the client's address.

For example, here's a snippet from a server side sqlnet.log where client address info was posted:

Production Time: 15-FEB-2010 07:15:01

Fatal NI connect error 12537, connecting to:
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(Host=yourhost)(Port=1521))(CONNECT_DATA=(SID=PROD1DR)(CID=(PROGRAM=sqlplus)(HOST=client_host)(USER=client))))

Observe the PROGRAM and HOST fields on the last line.  This is where the connection originated.
Be sure to match timestamps in the sqlnet.log with the timestamps of the alert.log errors.  Once you've located the offending client, you can enable client tracing to try and determine the cause:

TRACE_LEVEL_CLIENT=16
TRACE_DIRECTORY_CLIENT=