We have set this at a customer because their network equipment apparently
strips off the "urgent flag". I haven't seen any negative effects, but I
guess we would have to measure it in order to notice. I have seen this
parameter as a remedy for other issues as well at MOS.
2015-07-14 22:57 GMT+02:00 Peter Hitchman <pjhoraclel@xxxxxxxxx>:
Hi
All you are doing is stopping this client from sending a break via a
different channel to the server. So it might make things a bit less
efficient from the clients point of view, I guess it depends on exactly
what the client is doing.
Does the analyst think this is just a 11.2.0.3 issue combined with the
type of client you are using?
I saw issues like this years ago, back in the Oracle 8.0 days, but from
memory the disable_oob was a temp fix because the real issue was a client
using oci that as not up to date enough.
Regards
Pete
On 8 July 2015 at 14:14, Rich Jesse <rjoralist3@xxxxxxxxxxxxxxxxxxxxx>
wrote:
Hey all,
We've been getting sporadic ORA-3137 errors on our year-old 11.2.0.3 DB
since testing started. It doesn't appear to be a showstopper, as I can't
attribute any user complaints directly to these happening, so I've been
mostly ignoring these when they happen.
This week, I had an instance where the first parameter of the error
changed
from [12333] to [12271], so I thought it worth an SR. The tech pointed me
to MOS 1927582.1 that has a workaround of setting DISABLE_OOB=ON in the
sqlnet.ora of the client.
Has anyone used this? I can't find any negatives or side effects on MOS
about disabling it, but then why does OOB checking exist? It's like the
equivalent of an appendix in humans...
TIA!
Rich
--
//www.freelists.org/webpage/oracle-l
--
Regards
Pete
