Ich habe mir heute einen Beitrag in den MOSC-Foren über den Clustering Factor (CF) für einen Index angesehen. Eine Sache, die die Leute vergessen, wenn sie über die CF sprechen, ist, dass der DBA zwar einige Reorganisationsaktivitäten durchführen kann, um die CF für einen Index zu verbessern, dies jedoch möglicherweise auf Kosten eines anderen Index für dieselbe Tabelle geht. Betrachten Sie dieses Beispiel, das ich in diesem Thread bereitgestellt habe.
Hier habe ich eine Tabelle mit zwei Indizes. Es ist die einzige Tabelle in meinem Schema. Ein Index (IDX2) hat einen viel höheren CF als der andere (IDX1).
SQL> select index_name,clustering_factor from user_indexes;
INDEX_NAME CLUSTERING_FACTOR --------------- ----------------- MY_TAB_IDX2 135744 MY_TAB_IDX1 2257
Der DBA möchte dieses Problem „beheben“. Der DBA möchte den CF für IDX2 reduzieren. Der beste Weg, dies zu tun, besteht darin, die Daten aus der Tabelle zu ziehen und sie dann wieder einzufügen, sortiert nach den Spalten, auf denen IDX2 aufbaut.
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
Jetzt hat sich der CF für IDX2 definitiv verbessert. Aber schauen Sie sich die CF auf IDX1 an. Es wurde viel schlimmer. Tatsächlich schienen die beiden Indizes die CF-Werte umgedreht zu haben. Wenn ich eine weitere Reorganisation versuche, dieses Mal nach IDX1-Spalte(n) ordnend, werden die CF-Werte erneut umgedreht.
Die Moral dieser Geschichte ist, dass man nicht garantieren kann, dass die Verbesserung des CF für einen Index keine negativen Auswirkungen auf einen anderen Index dieser Tabelle hat.
