The workaround means you will not get the advantage of the
optimizer_adaptive_features which may from time to time reduce the actual
run time cost of executing some queries the 2nd through nth time the
instance is up. If you don't get enough advantage from these features that
you know about them, then this is likely less destabilizing and less risky
than applying a patch.
If you apply the patch, then you retain any advantage you are getting from
optimizer_adaptive_features at the cost of my general claim that any patch
has inherent risks greater than toggling a parameter to disable a
performance feature.
If someone has actual experience with this particular patch they may be able
to tell you whether or not there was any regression in Oracle behavior (or
that the patch had significant side effects; let's hope for the former).
If you have a sandbox and a regression suite that tests all your relevant
transactions and queries relevant to your production use for comparison, you
might be able to quickly verify that the patch does not break anything
important to you.
Good luck,
mwf
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Hsieh, Joan
Sent: Monday, August 17, 2015 11:36 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: oracle workaroud vs patch
Hi,
Our 12.1.0.2 database seems to hit the bug 18430870
<https://support.oracle.com/rs?type=bug&id=18430870> , ADAPTIVE PLAN AND
LEFT JOIN GIVE WRONG RESULT, there is a workaround to set the
optimizer_adaptive_features=false, also, there is a patch that Oracle
provides to fix the bug. I'd like to know what's pro's and con's for the 2
approaches. Should the work around is sufficient to deal with this bug?
Thanks,
Joan
