Днес разглеждах публикация във форумите на MOSC за фактора на клъстериране (CF) за индекс. Едно нещо, което хората са склонни да забравят, когато говорят за CF, е, че докато DBA може да извърши някаква реорганизация, за да подобри CF за даден индекс, това потенциално ще дойде за сметка на друг индекс за същата таблица. Помислете за този пример, който предоставих в тази тема.
Тук имам таблица с два индекса. Това е единствената таблица в моята схема. Един индекс (IDX2) има CF много по-висок от другия (IDX1).
SQL> select index_name,clustering_factor from user_indexes;
INDEX_NAME CLUSTERING_FACTOR --------------- ----------------- MY_TAB_IDX2 135744 MY_TAB_IDX1 2257
DBA иска да „поправи“ този проблем. DBA иска да намали CF за IDX2. Най-добрият начин да направите това е да извадите данните от таблицата и след това да ги вмъкнете обратно, сортирани по колоните, върху които е изграден 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.
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
Сега CF за IDX2 определено се подобри. Но вижте CF на IDX1. Стана много по-зле. Всъщност двата индекса изглежда са обърнали стойностите на CF. Ако опитам друга реорганизация, този път подреждане по колона(и) IDX1, тогава стойностите на CF ще се обърнат отново.
Моралът на тази история е, че не може да се гарантира, че подобряването на CF за един индекс няма да има отрицателно въздействие върху друг индекс от тази таблица.
