The is always a clash of goals here when it comes to SQL performance
a) When things are running well, we do *not* want the SQL plans to change
b) But when the data changes, we *want* the SQL plans to reflect the changed data
Of course, the ideal is that in (b), we only change SQL plans when we know things are going to better not worse. That is the optimizer's aim, but it does not always succeed.
I would recommend taking a look at SQL Plan Management (SPM) for a selection of business critical queries. SPM will lock a good running plan into place even if the optimizer finds what it thinks is a better one. The big benefit of SPM is that we will still *store* the new plan that the optimizer found, just not *use* it. You can then (from time to time) look at these new plans and decide to see if they are *truly* better.
Optimizer product manager Nigel Bayliss has an excellent white paper on SPM
https://blogs.oracle.com/optimizer/new-sql-plan-management-white-paper