Patrzyłem dziś na post na forach MOSC na temat Clustering Factor (CF) dla indeksu. Jedną rzeczą, o której ludzie zwykle zapominają, mówiąc o CF, jest to, że chociaż DBA może wykonać pewne czynności reorg, aby poprawić CF dla indeksu, potencjalnie będzie to kosztować inny indeks dla tej samej tabeli. Rozważ ten przykład, który podałem w tym wątku.
Tutaj mam tabelę z dwoma indeksami. To jedyna tabela w moim schemacie. Jeden indeks (IDX2) ma znacznie wyższy CF niż drugi (IDX1).
SQL> select index_name,clustering_factor from user_indexes;
INDEX_NAME CLUSTERING_FACTOR --------------- ----------------- MY_TAB_IDX2 135744 MY_TAB_IDX1 2257
DBA chce „naprawić” ten problem. DBA chce zmniejszyć CF dla IDX2. Najlepszym sposobem na to jest wyciągnięcie danych z tabeli, a następnie wstawienie ich z powrotem, posortowane według kolumn, na których zbudowany jest IDX2.
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.zatwierdzenie
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
Teraz CF dla IDX2 zdecydowanie się poprawiła. Ale spójrz na CF na IDX1. Pogorszyło się znacznie. W rzeczywistości te dwa indeksy wydawały się odwrócić wartości CF. Jeśli spróbuję wykonać inną reorg, tym razem według kolumny (kolumn IDX1), wartości CF ponownie się odwrócą.
Morał z tej historii jest taki, że nie można zagwarantować, że poprawa CF dla jednego indeksu nie będzie miała negatywnego wpływu na inny indeks w tej tabeli.
