-
Here is how i collected statistics on my materialized view:
execute dbms_stats.gather_table_stats(ownname=> 'MUS_GEN3', tabname=> 'MV_SONG' , estimate_percent=>
DBMS_STATS.AUTO_SAMPLE_SIZE, cascade=> DBMS_STATS.AUTO_CASCADE, degree=> null, no_invalidate=> DBMS_STATS.AUTO_INVALIDATE,
granularity=> 'AUTO',method_opt=> 'FOR ALL COLUMNS SIZE AUTO');
Will cascade=> DBMS_STATS.AUTO_CASCADE collect stats on indexes related to my mv?
Should i have collected stats on my mv a different way?
The index used in the plan is correct btw, the same as in my dev database.
It is the bitmap conversion that is not right. So by increasing the “blevel” or leaf blocks values in one of the indexes will make the plan use another index? Or simply stop bitmap conversion on me?
And again, there is no bitmap index in my database. I have a oltp system.
-
its nothing to do with bitmap indexes, so dont get confused. If it causing you a problem set that parameter pando mentioned
-
_b_tree_bitmap_plans is already set to false. It is still happening.
-
Have you checked the bugs I posted earlier?
-
Im on 10.2.0.3. The metalink note is for 9i. The doc says to change the parameter wish i did.
-
-
When talking about bugs, you don't trust literally what a Oracle Note says about affected versions.
You are in 10g and bug affected 9i?... check the date of the note, chances are Ora10g wasn't an active product when it was written. Bug might be there, alive and kicking
-
I have change the parameter, still happening.
-
so why not try using index/es hint?