19C数据库alter日志出现少量ORA-12637包接收失败的错误

环境介绍：
os：8.2
db:19.13

问题现象
Fatal NI connect error 12637, connecting to:
(ADDRESS=(PROTOCOL=tcp)(HOST=172.16.73.157)(PORT=52687))

  VERSION INFORMATION:
        TNS for Linux: Version 19.0.0.0.0 - Production
        Oracle Bequeath NT Protocol Adapter for Linux: Version 19.0.0.0.0 - Production
        TCP/IP NT Protocol Adapter for Linux: Version 19.0.0.0.0 - Production
  Version 19.13.0.0.0
  Time: 05-MAY-2023 07:50:55
  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
2023-05-05T07:50:55.167759+08:00
opiodr aborting process unknown ospid (862230) as a result of ORA-609
2023-05-05T07:50:55.168086+08:00
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_ora_862230.trc:
ORA-00609: could not attach to incoming connection
ORA-12637: Packet receive failed

查看sqlnet.ora文件
[oracle@hisdb1 admin]$ ll
total 12
drwxr-xr-x 2 oracle oinstall    6 Nov  5  2021 mkdir
drwxr-xr-x 2 oracle oinstall   64 Apr 17  2019 samples
-rw-r--r-- 1 oracle oinstall 1536 Feb 14  2018 shrept.lst
-rw-r--r-- 1 oracle oinstall  139 Nov 28 16:06 sqlnet.ora
-rw-r----- 1 oracle oinstall 1050 Nov  5  2021 tnsnames.ora
[oracle@hisdb1 admin]$ more sqlnet.ora
SQLNET.ALLOWED_LOGON_VERSION_SERVER=8
SQLNET.ALLOWED_LOGON_VERSION_CLIENT=8

#SQLNET.AUTHENTICATION_SERVICES = (NTS)
SQLNET.EXPIRE_TIME=2

搜索MOS，找到一篇类似文章：
Changes

New Feature added to 19c. Client will trigger the server to test for OOB availability at connect time. If it fails the error is reported.
Cause

New feature in 19c client that will trigger the server to Auto test if Out of Bound breaks are allowed on the network.
This is on by default.

So when the 19c client connects to the server it will trigger the server to test OOB this is seen in the server side trace
nsaccept: Checking OOB Support

If the network underneath does not support the OOB the OOB check will fail. The connection will also fail.



Solution

The True solution in this case would be to resolve the underlying network inability to handle Out of Bound packets.
The network should support those in order to handle things like using a Control C to interrupt the communication between the client and server.


In the meantime you can use the following workarounds.

Option 1
To stop the initial OOB check you can use the parameter
5.2.8 DISABLE_OOB_AUTO
https://docs.oracle.com/en/datab ... vices-reference.pdf

Please note if you do require an OOB break later in the life of the connection it will likely also fail and cause a failure later in the life of the connection.
So not the best option.

Second option
DISABLE_OOB=ON in the SQLNET.ORA file on the server.
https://docs.oracle.com/en/datab ... vices-reference.pdf


This will turn off the OOB usage until you can resolve the underlying network inability to handle the packets.
Long term we prefer to keep OOB in use to allow things like a Control C to be able to function normally.
So it is best to only use this as a workaround and fix the true underlying network inability to handle the OOB packets.

Additional Note
While checking the network make sure it can also support the URG flag as that is also required by the Oracle software and from external reading often also prevented when the OOB packets are not allowed.