In unserer täglichen Praxis erleben wir häufig, dass Indizes beim Kunden sehr groß geworden sind. In vielen Fällen wurden in der zum Index gehörenden Tabelle viele Einträge gelöscht. Wenn nicht die Tabelle die gleichen Einträge wieder auffüllt, können Lücken im Index entstehen, die dazu führen, dass der Index sich unnötigerweise aufbläht.
Beispiel: Herr Huber wird aus der Kundentabelle gelöscht, Herr Meyerhuber kommt neu dazu.
Ein Index auf der Namensspalte fragmentiert dadurch. Wie kann man nun herausfinden, ob der Index ein Kandidat für einen Neuaufbau ist? Führen Sie dazu eine ausführliche Analyse des Index durch mit:
ANALYZE INDEX scott.emp_ind VALIDATE STRUCTURE;
Dadurch wird eine weitere Tabelle (index_stats) mit Informationen gefüllt:
SELECT
DEL_LF_ROWS*100/decode(LF_ROWS, 0, 1, LF_ROWS) PROZ_GELOESCHT,
(LF_ROWS-DISTINCT_KEYS)*100/ decode(LF_ROWS,0,1,LF_ROWS) DISTINCTIVENESS
FROM index_stats;
PROZ_GELOESCHT gibt an, wieviel Prozent der Indexeinträge gelöscht und nicht wieder gefüllt wurden. Je höher dieser Wert ist, desto schlechter ist der Indexbaum ausbalanciert. Ab 10 % kann und ab 20 % sollte reorganisiert werden.
DISTINCTIVENESS gibt an, wie häufig ein Indexwert wiederholt vorkommt (<Ges. Anzahl>/ <anz. verschiedener Werte>) *100 / <Ges. Anzahl>. Bei häufiger Wiederholung (z.B. bei 90% sollte ein Bitmap-Index in Betracht gezogen werden).
Hinweis:
Ein Index Rebuild können Sie wie folgt vornehmen:
ALTER INDEX <owner>.<index_name> REBUILD; /* Tabelle zum Schreiben gesperrt, für Standard Edition */
ALTER INDEX <owner>.<index_name> REBUILD ONLINE; /* Tabelle zum Schreiben NICHT gesperrt, für Enterprise, Express und Personal Edition */
oder mit Speicherparametern:
ALTER INDEX <owner>.<index_name> REBUILD ONLINE
TABLESPACE <indx_tbs> STORAGE (INITIAL <n>M NEXT <n>M);