alter日志出现ORA-00609 and ORA-12547
发布时间：2022-11-02
os:rhel8.2
db:19.13
异常描述：在巡检时发现log文件存在以下告警：
db:19.13
异常描述：在巡检时发现log文件存在以下告警：
2022-08-22T23:59:44.481409+08:00
Errors in file/u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_ora_119252.trc:
ORA-00609: could notattach to incoming connection
ORA-12547: TNS:lostcontact
Mos[ID 2813629.1]文档与以上场景类似
Applies to:
Symptoms
Changes
Cause
Solution
JDBC - Version 11.2.0.4.0 and later
Information in this document applies to any platform.
After upgrading the database from 11.2.0.4 to 19c with April PSU 2021, an application using JDBC 11.2.0.4 is reporting the following errors in the database alert log:
opiodr aborting process unknown ospid (<OSPID>) as a result of ORA-609
..
ORA-00609: could not attach to incoming connection
ORA-12547: TNS:lost contact
opiodr aborting process unknown ospid (<OSPID>) as a result of ORA-609
..
ORA-00609: could not attach to incoming connection
ORA-12547: TNS:lost contact
Often the ORA-609 is reported due to client disconnecting before the connection can be established fully.
The issue is caused by a communication break that occurred on the underlying network level. It is related to Out of bound data which is used for break and reset functionality.
Oracle TWO_TASK layer has break/reset logic to make sure that both the client and server are in sync. The break/reset logic works effectively if the operating system supports OOB (out-of-band breaks). Depending on the JDBC version and oracle.net.disableOob flag, the cancel request is either issued using the TCP urgent bit (disableOob=false and "break" messages are sent using urgent data provided by the underlying protocol) .OR using a mechanism that relies on the database polling for cancel requests (disableOob=true which uses in-band breaks). Ultimately the cancel request needs to be acknowledged and processed by the database.
Out Of Band Breaks (OOB) are enabled by default provided the underlying protocol supports sending urgent data.
From JDBC Driver 11g onwards, JDBC supports out-of-band breaks (OOB) in preference to in-band breaks, and it requires the urgent flag for the communication.
More information can be found in:
What is DISABLE_OOB (Out Of Band Break)? (Doc ID 373475.1)
JDBC Session Stays In The Database After The Java Program Was Canceled Using CTRL + C (Doc ID 1394687.1) .
Database 19c now performs a check up front to see if that OOB packet is allowed on the network or not.
The issue is caused by a communication break that occurred on the underlying network level. It is related to Out of bound data which is used for break and reset functionality.
Oracle TWO_TASK layer has break/reset logic to make sure that both the client and server are in sync. The break/reset logic works effectively if the operating system supports OOB (out-of-band breaks). Depending on the JDBC version and oracle.net.disableOob flag, the cancel request is either issued using the TCP urgent bit (disableOob=false and "break" messages are sent using urgent data provided by the underlying protocol) .OR using a mechanism that relies on the database polling for cancel requests (disableOob=true which uses in-band breaks). Ultimately the cancel request needs to be acknowledged and processed by the database.
Out Of Band Breaks (OOB) are enabled by default provided the underlying protocol supports sending urgent data.
From JDBC Driver 11g onwards, JDBC supports out-of-band breaks (OOB) in preference to in-band breaks, and it requires the urgent flag for the communication.
More information can be found in:
What is DISABLE_OOB (Out Of Band Break)? (Doc ID 373475.1)
JDBC Session Stays In The Database After The Java Program Was Canceled Using CTRL + C (Doc ID 1394687.1) .
Database 19c now performs a check up front to see if that OOB packet is allowed on the network or not.
Option 1.
Make sure that URG flag is allowed for Oracle and that out of bound data is allowed on the network level.
This is not limited to switches, routers and firewalls, but also on the individual node level.
Or,
Option 2
set DISABLE_OOB=ON in the database sqlnet.ora.
This will simply change the flag to not use the URG flag and send the same break and reset packets in line instead of out of bound with the URG flag.
Make sure that URG flag is allowed for Oracle and that out of bound data is allowed on the network level.
This is not limited to switches, routers and firewalls, but also on the individual node level.
Or,
Option 2
set DISABLE_OOB=ON in the database sqlnet.ora.
This will simply change the flag to not use the URG flag and send the same break and reset packets in line instead of out of bound with the URG flag.
