By: Wolfgang Breitling

Wolfgang Breitling — Tue, 11 Mar 2008 09:02:13 +0000

“for partitioned tables only? or all, Iâ€™m not sure”.
My apologies if I didn’t make something clear enough. I can only guess that you are referring to the problem of ending up with an incorrect low or high value for a predicate column when cloning statistics. How the CBO calculates the selectivity of equality predicates has changed dramatically from 9i to 10g. If the predicate value is outside the low_value-high_value range, 9i used num_distinct or density to calculate the selectivity which is used for row source cardinality and index access cost calculation. 10g detects the “out-of-range value pred” and assigns as selectivity of 1/(2*num_rows) to the predicate. Ultimately that leads to all indexes which have that column anywhere in the column list, even if it is the last column, to be assigned the same cost: blevel+2. If the cost of two or more indexes is the same, in this case if they have the same height, the index tie-break by name decides which index is being chosen. That can be very bad for the performance.
Back to your question “for partitioned tables only? or all”. In principle it applies to all cloning. However, you will likely encounter it more often with partitions simply because if you clone statistics you are more likely to clone the statistics of an existing partition to a new partition because that falls under regular maintenance. But it could also happen if you clone your production statistics to development, or your QA statistics to production.

Comments on: Hotsos 2008, day 2

By: Wolfgang Breitling