The Reference MOS documentation is:
Troubleshooting Guide ORA-609:OPIODR aborting process unknown ospid (document ID 1121357.1)
Alert.log shows ORA-609 with Tns-12537:tns:connection closed (document ID 1538717.1)
Fatal NI Connect 12560 ' and ' ORA-609 Opiodr aborting Process ' Errors in the Alert Log (document ID 987162.1)
In the database alert log, we often see ORA-609, ora-3136/ora-609 TNS-12537 and TNS-12547 or TNS-12170 12170, ' TNS-12535 and other related errors, to summarize this type of problem, as follows:
Troubleshooting Guide for 1.ora-609 errors:
Alert Log can see the following error message:
Fatal NI Connect error 12537, connecting to:
(Local=no)
VERSION Information:
TNS for Linux:version 11.2.0.3.0-production
Oracle bequeath NT Protocol Adapter for Linux:version 11.2.0.3.0-production
TCP/IP NT Protocol Adapter for Linux:version 11.2.0.3.0-production
time:26-feb-2013 02:23:51
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 (28725) as a result of ORA-609
First an explanation of kind of errors.
The message
OPIODR aborting process unknown ospid (...) as a result of ORA-609
is just a notifications, Oracle database closed (aborted) a dedicated process because of ORA-609.
ORA-609 means "could not attach to incoming connection" so the database process was ' aborted ' (closed) because it couldn ' T attach to the incoming connection passed to it by the listener.
The reason for found in the sqlnet error stack
Tns-12537:tns:connection closed.
Basically the dedicated process didn ' t has a client connection anymore to work with.
This error is similar to notification: Oracle is shut down by ORA-609 or called aborted a proprietary connection to the database--ospid (28725).
ORA-609 error reason is: Unable to contact the incoming connection, so the connection cannot be transferred to the listener, so the database process aborts the process.
At this time error tns-12537:tns:connection closed, the root cause for the client connection is not normal.
The process by which clients connect to an Oracle database through a listener:
1. Client initiates a connection to the database so it connects to the listener
2. Listener starts (fork) a dedicated database process that would receive this connection (session)
3. After this dedicated process was started, the listener passes the connection from the client to this process
4. The server process takes the connection from the listener to continue the handshake with the client
5. Server process and client exchange information required for establishing a session (ASO, Task Common, User logon )
6. Session is opened
Simply put:
1. Client connection to Listener
2. Listen for a sub-process derived fork, turn it into a proprietary server process dedicated database processes
3. After the 2nd step is completed, the listener transfers the client connection to this proprietary process dedicated processes
4. After the server process receives the connection information from the listener, it needs to continue the connection with the client handshake
5. Server process Exchange with client process information required to establish a session, such as user name, password, etc.
6. After OK, SESSION OPEN.
When a client connection is closed at 3 or 4 steps, dedicated database process discovers that the client is turned off when communicating with the client.
Use tracing to troubleshoot:
Documentation: Troubleshooting Guide ORA-609:OPIODR aborting process unknown ospid (document ID 1121357.1)
For troubleshooting this problem, using Listener.log or sqlnet tracking is not good, because there may be many connections per second and sqlnet traces do not provide more client information.
You can attempt to use OS-level tracing at this point.
such as: 1111 for the monitoring process, ps-ef|grep Tnslsnr isolated
Linux:strace-rf-o/tmp/lsnr1.log-p 1111
HP-UX:TUSC-T Hires-afpo/tmp/lsnr1.log 1111
If you use trace tracing, the following:
3. Oracle Net level Server tracing. Add to server side sqlnet. ORA file
Diag_adr_enabled=off # Disable ADR if version 11g
Trace_level_server = # Enable level trace
Trace_timestamp_server = on # Set TIMESTAMP in the trace files
Trace_directory_server = <DIRECTORY> # Control trace File location
Trace_filelen_server =<n> #Control size of trace set in kilobytes eg 20480
Trace_fileno_server =<n> #Control number of trace files per process
Use the Errorstack method as follows:
4. Errorstack:setup Errorstack to capture failure. This can being particular useful when capturing a Oracle Net client trace is not feasible.
Sql> alter session SET events ' 609 Errorstack (3) ';
Once a few traces has been collected while the error is reproduced:
Sql> alter session set events ' 609 off ';
The workarounds for this issue are:
Documentation: Alert.log shows ORA-609 with Tns-12537:tns:connection closed (document ID 1538717.1)
Possible causes:
The client is stuck, crashes, the connection is blocked by the firewall, client timeout is set, the client shuts down immediately after connection, and the network is unstable;
You need to check the information in the client Tnsnames.ora/sqlnet.ora:
Possible timeouts in Sqlnet.ora in client Oracle home:
Sqlnet.outbound_connect_time
Sqlnet.recv_timeout
Sqlnet.send_timeout
Tcp_connect_timeout
Possible timeout in client connect descriptor (hardcoded in client application or in client Tnsnames.ora):
Connect_timeout
Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.
One of the most common listening errors in alert logs: ORA-609 error troubleshooting
