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
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.
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.
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.