Here's Oracle's response - looks like there IS something different in 19c.
I'm going to submit an Enhancement Request to make this a WARNING rather than a
failure.
Now the reason this differs in 19 is because they did add something new in 19c.
It was not the OOB default as those notes indicate it is that we check for the
ability to OOB up front now.
In the server side trace you will see
nsaccept: Checking OOB Support.
This is a new function to see if OOB is enabled on this connection.
Now the True aspect here is that OOB check is failing because your network is
dropping it. So your network is not a fan of the OOB flag.
That is why setting disable_oob worked fine because we then no longer do that
check.
We dont see it in the other trace because we wont check that one unless we use
an OOB.
Now please note in that setup I suggest until you address the OOB flag on your
network you may want to also set it for the working 12 clients.
The reason I say that is because if you later choose to do a control C or other
valid reason to send an OOB flagged packet since your network does not like it
it will generate a failure then.
So the only reason the 19 client is more sensitive is because we test OOB now
up front and the other client wont know of that problem till later.
They also added a new parameter
5.2.8 DISABLE_OOB_AUTO
https://docs.oracle.com/en/database/oracle/oracle-database/20/netrf/database-net-services-reference.pdf
Use the sqlnet.ora profile parameter DISABLE_OOB_AUTO to disable server
pathchecks for out-of-band break messages at the time of the connection.
Purpose
To disable sqlnet.ora from checking for out-of-band (OOB) break messages in the
server path at connection time.
Usage Notes
By default, the client determines if the server path supports out-of-band break
messages at the time of establishing the connection.
If DISABLE_OOB_AUTO is set to TRUE, then the client does not perform this check
at connection time.
Default
FALSE
So that is another option to workaround this issue you have is to turn off the
check.
however please note if you try to use an OOB later in the connection you may
run into issues.
So likely best to just use DISABLE_OOB=ON in BOTH versions until you talk to
the network admins to have them allow Out of bound break and Urg flags as
Oracle will use those features for not only the control C but also for the
Break And reset logic that we use to insure the logic is correct if the client
and server end up out of sync for some reason.
Clay Jackson
Database Solutions Sales Engineer clay.jackson@xxxxxxxxx
office 949-754-1203 mobile 425-802-9603
-----Original Message-----
From: Clay Jackson (cjackson)
Sent: Wednesday, April 22, 2020 4:35 PM
To: gogala.mladen@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: RE: ORA-12367 with 19c Client
Hi, Mladen -
Sayan and I have the same issue, solved by setting DISABLE_OOB=YES. We're
still doing some testing; but, based on a quick test we ran from a Linux server
(which worked), it LOOKS like this may be a Docker (which is where Sayan found
the fix) and Windows specific issue. The Docker note implies that.
Stay tuned!
Clay Jackson
Database Solutions Sales Engineer clay.jackson@xxxxxxxxx office 949-754-1203
mobile 425-802-9603
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx> On Behalf
Of Mladen Gogala
Sent: Wednesday, April 22, 2020 4:22 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: ORA-12367 with 19c Client
CAUTION: This email originated from outside of the organization. Do not follow
guidance, click links, or open attachments unless you recognize the sender and
know the content is safe.
Hi Sayan!
Does that happen only when connecting to 19.3 database or it also transpires
when connecting to 19.6 or 19.7? I am using Oracle instant client version 19.5
and Mumbai.exe connects without a problem to Oracle
19.7 on Linux.
Regards
On 4/22/20 12:07 PM, Sayan Malakshinov wrote:
Yes, I had the same problem:
https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwit
ter.com%2Fxtner%2Fstatus%2F1235918336241868802&data=02%7C01%7Cclay
.jackson%40quest.com%7Cd839fef89b984a11b4c308d7e7140a51%7C91c369b51c9e
439c989c1867ec606603%7C0%7C0%7C637231945566216873&sdata=GRY4g9yTTV
QXJJHiLbqwLC4dMXIwd4IsaD2K8EL6wAQ%3D&reserved=0
Oracle windows clients 19.3 and 19.5 fail to connect to Oracle 19.3with "ORA-12637: Packet receive failed". Oracle clients <19 work
fine... and i haven't found public bug for that.
