Re: Priority of profile baseline patch

Thank You So much Jonathan.

Attached is the sql hints/outline of the profile which is pushed through dbms_sqltune.import_sql_profile procedure.

And yes this query is having two of the tables MTD and MDD both are partitioned. And there are ~97 index partitions for table MDD for one of the indexes which is in UNUSABLE state. However that query is going for a full table scan on that table MDD in the plan.So can that still cause such a plan issue because of those unusable index partitions? But yes that column on which index is created is part of the join condition in this query, is it because that optimizer is going for that table expansion Or dividing the query evaluation into multiple pieces, even though showing full scan in the plan in each of the expanded sections?

expand_table hint is used for MDD table in the outline section even for the sql profile. So wondering , as Lok pointed, how this OR_EXPAND of two predicates now becomes non reproducible and it's going for three predicates/sets plan?

On Wed, Dec 22, 2021 at 3:42 PM Jonathan Lewis <jlewisoracle_at_gmail.com> wrote:

> 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_at_gmail.com> 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?
>>
>
>

--
http://www.freelists.org/webpage/oracle-l




text/plain attachment: list_profile_outline.txt