Jonathan
They are all after newly added and conventionally loaded partitions on
which statistics for conventional DML is used. The application is then
re-running fresh statistics on the newly added partition every 2 hours. Now
those queries are back to their good plan. But I would like to avoid such a
case of execution plan switch. The first optimized execution plan (the one
on which Oracle realizes that it has a cardinality misestimates and marked
the underlying cursor for a new re-optimization) was a very good one J
So, now thinking whether canceling statistics feedback on those queries
will help to avoid this plan switch
Best regards
Mohamed
Le mar. 27 avr. 2021 à 15:04, Jonathan Lewis <jlewisoracle@xxxxxxxxx> a
écrit :
Mohamed,
Have you spotted any common pattern to the 6 unlucky queries?
Regards
Jonathan Lewis
On Tue, 27 Apr 2021 at 13:53, Mohamed Houri <mohamed.houri@xxxxxxxxx>
wrote:
Hello Sayan
Thanks for your answer. It confirms why I haven't experienced any
performs pain with cardinality feedback in all the 19c databases I have to
deal with. Until today where 6 critical queries changed their execution
plan from a good one to a very bad one and the non-sharing reason was
USE_FEEDBACK_STATS
Best regards
Mohamed
