alert_sid.log中有如下报错信息
Wed Dec 18 08:25:58 2013 *********************************************************************** Fatal NI connect error 12537, 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 - Production TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.1.0 - Production Time: 18-DEC-2013 08:25:58 Tracing not turned on. Tns error struct: ns main err code: 12537 TNS-12537: TNS:connection closed ns secondary err code: 12560 nt main err code: 0 nt secondary err code: 0 nt OS err code: 0 opiodr aborting process unknown ospid (16596) as a result of ORA-609 Wed Dec 18 08:28:25 2013 Thread 1 advanced to log sequence 22477 (LGWR switch)
MOS给出的解决方法
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. A setting of 120 seconds should resolve most if not all ORA-609 errors.
As explained in the Cause section, The ORA-609 error is thrown when a client connection of any kind failed to complete or aborted the connection process, so ORA-609 and TNS- errors are expected while shutting down the database - as client connection will fail to complete or aborted the connection process before the connection/authentication process was complete. So please ignore the ORA-609 and TNS- errors, if these are appear while database instance is shutting down.
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 sqlnet.ora file parameter:
sqlnet.ora file (on the server): DIAG_ADR_ENABLED = OFF
Reload the listener following this change.
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:
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=
TRACE_TIMESTAMP_CLIENT=TRUE
DIAG_ADR_ENABLED=off <<<
If you need assistance with client or server tracing, please open an SR with Global Customer Support.
2) Check the listener.log for client connections that were logged at timestamps that match the ORA-609 timestamps as they appear in the alert.log. The client information is recorded in each listener.log entry.