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
