I’ve always found it tricky to explain to a victim that actually the plan that used to work so well was picked for the wrong reasons and it’s now picking a much worse plan but for the right reasons.

A recent example for this: a query which run perfectly well in 9iR2 started to run very slow in 11gR2. It is a simple join with couple of filter conditions on both tables. Due to the fact that CBO in 9i had no idea that data in two columns is correlated, it considered two plans, both low cost but picked the first it considered. CBO was blind in 9i and cardinality estimates were way off for both tables, but it was the right plan. In 11g, however, it was able to calculate selectivity for a condition on two columns of the table based on an index’s distinct_keys. That implied change in the order of plans. Both are the same low cost, but the first is totally wrong, because, well, there are several conditions (including like ‘X%’) and all of them are not selective at all, which is enough to screw things up.