Ik keek vandaag naar een bericht op de MOSC-forums over de Clustering Factor (CF) voor een index. Een ding dat mensen geneigd zijn te vergeten als ze over de CF praten, is dat hoewel de DBA wat reorganisatie-activiteiten kan doen om de CF voor een index te verbeteren, dit mogelijk ten koste gaat van een andere index voor diezelfde tabel. Beschouw dit voorbeeld dat ik in die thread heb gegeven.
Hier heb ik een tabel met twee indexen. Het is de enige tabel in mijn schema. De ene index (IDX2) heeft een veel hogere CF dan de andere (IDX1).
SQL> select index_name,clustering_factor from user_indexes;
INDEX_NAME CLUSTERING_FACTOR --------------- ----------------- MY_TAB_IDX2 135744 MY_TAB_IDX1 2257
De DBA wil dit probleem "oplossen". De DBA wil de CF voor IDX2 verlagen. De beste manier om dat te doen, is door de gegevens uit de tabel te halen en vervolgens weer in te voegen, gesorteerd op de kolom(men) waarop IDX2 is gebouwd.
SQL> create table my_tab_temp as select * from my_tab;
Table created.
SQL> truncate table my_tab;
Table truncated.
SQL> insert into my_tab select * from my_tab_temp order by pk_id;
135795 rows created.
SQL> commit;
Commit complete.
SQL> exec dbms_stats.gather_table_stats(ownname=>USER,tabname=>'MY_TAB',cascade=>TRUE);
PL/SQL procedure successfully completed.
SQL> select index_name,clustering_factor from user_indexes;
INDEX_NAME CLUSTERING_FACTOR --------------- ----------------- MY_TAB_IDX2 2537 MY_TAB_IDX1 135747
Nu is de CF voor IDX2 zeker verbeterd. Maar kijk naar de CF op IDX1. Het werd veel erger. In feite leken de twee indexen de CF-waarden te hebben omgedraaid. Als ik een andere reorganisatie probeer, deze keer op volgorde van de IDX1-kolom(men), dan zullen de CF-waarden weer omdraaien.
De moraal van dit verhaal is dat men niet kan garanderen dat het verbeteren van de CF voor de ene index geen negatief effect zal hebben op een andere index van die tabel.