You've got Table expansion, OR-expansion, and Join factorization going on
in the old plan, but the join factorization does not occur in the new plan.
The significant factor is probably the Table expansion - this suggests you
have some partial indexing in place, or some partitions of local indexes
that are currently unusable. If there was something about the pattern of
"missing" index data that FORCED oracle to use a 3-way OR-expansion then
everything else follows from there.
Have you posted the content of the profile yet ? If so I missed it.
Regards
Jonathan Lewis
On Mon, 20 Dec 2021 at 20:19, Pap <oracle.developer35@xxxxxxxxx> wrote:
Thank You So much Jonathan.
I think you are spot on wrt the OR expansion point. The plan which I am
seeing now is not getting reproduced and thus causing a new
baseline generation is having OR expansion. And thus the total number of
lines in this new plan is ~113 as compared to ~87 in the earlier plan. I
have attached the sample query with the old plan and the new one with their
respective outlines.
But yes the question would be why optimizer is now not able to produce the
old plan(i.e mostly without OR expansion). No such object definition change
or parameter setup changes have been done. Statistics are getting gathered
on a daily basis on the underlying objects but that should not cause such
issues. And this plan suddenly appeared after a particular date and is
continuing now. And the note section in the new plan is showing the section
below (i.e. it failed to reproduce the baseline). And used the sql profile,
but the sql profile plan/old plan is not exactly the same as this one.
We have not had any sql patch created here but yes the sql profile was not
created using the traditional method(which would have a bunch of
opt_estimate hints) rather its created by forcing the exact outline hints
of an awr plan i.e the old plan in the attached doc. So do you think that
forced outline hints through sql profile can cause such an issue?
