Je regardais aujourd'hui un article sur les forums MOSC sur le facteur de clustering (CF) pour un index. Une chose que les gens ont tendance à oublier lorsqu'ils parlent du CF est que même si le DBA peut faire une activité de réorganisation pour améliorer le CF d'un index, cela se fera potentiellement au détriment d'un autre index pour cette même table. Considérez cet exemple que j'ai fourni dans ce fil.
Ici, j'ai une table avec deux index. C'est la seule table de mon schéma. Un indice (IDX2) a un CF beaucoup plus élevé que l'autre (IDX1).
SQL> select index_name,clustering_factor from user_indexes;
INDEX_NAME CLUSTERING_FACTOR --------------- ----------------- MY_TAB_IDX2 135744 MY_TAB_IDX1 2257
Le DBA veut "résoudre" ce problème. Le DBA veut réduire le CF pour IDX2. La meilleure façon de le faire est d'extraire les données de la table, puis de les réinsérer, triées par la ou les colonnes sur lesquelles IDX2 est construit.
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.validation
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
Maintenant, le CF pour IDX2 s'est définitivement amélioré. Mais regardez le CF sur IDX1. C'est devenu bien pire. En fait, les deux indices semblaient avoir inversé les valeurs de CF. Si je tente une autre réorganisation, cette fois en triant par la ou les colonnes IDX1, les valeurs CF s'inverseront à nouveau.
La morale de cette histoire est qu'on ne peut pas garantir que l'amélioration du CF pour un index n'aura pas d'effet négatif sur un autre index de cette table.
