通过ORA-609深入理解监听的原理

Fatal NI connect error 12537, connecting to:
(LOCAL=NO)

VERSION INFORMATION:
TNS for Linux: Version 12.2.0.1.0 - Production
Oracle Bequeath NT Protocol Adapter for Linux: Version 12.2.0.1.0 - Production
TCP/IP NT Protocol Adapter for Linux: Version 12.2.0.1.0 - Production
Time: 04-NOV-2021 15:209: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 (299904) as a result of ORA-609

这是报错的alert日志内容，下面分析这个报错，总体上看是tns网络连接时出问题了，到底是哪里有问题呢，先看看这个错误
opiodr aborting process unknown ospid (299904) as a result of ORA-609
其含义是Oracle由于发现了ORA-609错误而abort了数据库服务器进程，ORA-609的含义是不能完成与客户端的连接，所以服务器进程
被关闭了，而具体的错误再sqlnet错误堆栈中给出，即：TNS-12537: TNS:connection closed.
下面我们分析下Oracle网络连接的完整流程：
1 客户端发起到数据库监听的连接，注意这里不是直接连接到数据库。
2监听为要连接的数据库中fork一个服务器进程，服务器进程接手这个连接。
3 服务器进程启动后，监听将客户端的连接转给服务器进程。
4 服务器进程接手从监听传递过来的到客户端的连接，继续完成与客户端的握手过程。
5 服务器进程和客户端交换建立连接的信息。
6 会话打开，开始通信
而ORA-609错误发生再3，4步骤之间，即服务器进程尝试与客户端通信，发现连接关闭了。

由于sqlnet的trace不会提供任何信息，所以需要开启sqlnet server trace功能来捕获错误
此时需要设置服务器端Net Level 16的跟踪，如下所示
DIAG_ADR_ENABLED=off # Disable ADR if version 11g
TRACE_LEVEL_SERVER = 16 # Enable level 16 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

由于QLNET.ORA再进程创建时仅仅读一次，所以RDBMS的后台进程需要重启，为了方便我们可以设置Errorstack
SQL> alter system set events '609 errorstack(3)';
当ORA-609重新后关闭改事件

SQL> alter session set events '609 off';

生产库中改类问题往往存在时间较短，在没有设置跟踪情况下不易及时捕捉，通常的解决方法是
设置参数在目录RDBMS_HOME/network/admin中sqlnet.ora文件中设置参数SQLNET.INBOUND_CONNECT_TIMEOUT
改参数默认为60秒，我们设置300秒，延长报错时间。
SQLNET.INBOUND_CONNECT_TIMEOUT=300

下面是常见原因：
1客户端关闭了连接。
2 客户端crash
3 防火墙关闭连接
4 客户端设置了超时参数
5 DB层或者OS层性能问题，导致连接进程受到影响。