Dienstag, August 18, 2015

Indizes löschen

Jonathan Lewis hat - wieder einmal angeregt durch entsprechende Fragen in den OTN-Foren - einen Artikel zur Frage geschrieben: welche Informationen muss man analysieren, um bestimmen zu können, ob ein Index gefahrlos gelöscht werden kann? Bisher ist es zwar nur ein Artikel, aber da ein zweiter angekündigt ist, mache ich gleich eine Aufzählung daraus:

Erklärt zunächst das grundsätzliche Probleme extremer Indizierung: zwar wird - potentiell - die Treffsicherheit der Zugriffe erhöht, aber man bezahlt dafür mit einer massiven Vergrößerung von undo/redo für die Index-Maintenance. Insofern erscheint es naheliegend, überflüssige Indizes zu löschen - also solche, die in den Ausführungsplänen des Optimizers nicht erscheinen -, aber dabei ergeben sich oft Schwierigkeiten:
  • die Tatsache, dass ein Index benutzt wird, bedeutet nicht unbedingt, dass er auch benutzt werden sollte. Möglicherweise übersieht der Optimizer einen geeigneteren Index.
  • das bedeutet im Gegenzug natürlich auch, dass ein unbenutzter Index unter Umständen benutzt werden sollte.
  • die Statistiken eines Index (insbesondere die Anzahl distinkter Einträge) sind eine Information, die der Optimizer berücksichtigen kann, auch wenn ein Index nicht in Query-Plänen erscheint. Theoretisch kann man diese Information auch über extended statistics erfassen, aber mehr als 20 column groups kann man damit pro Tabelle nicht erfassen.
  • unbenutzte Indizes können als Lösung des berüchtigten foreign key locking-Problems eine Rolle spielen.
Zur Bestimmung der tatsächlichen Verwendung gibt es diverse Hilfsmittel, die allerdings jeweils ihre spezifischen Beschränkungen haben:
  • v$object_usage: hat eine beschränkte Aussagekraft, da die View nur eine simple ja/nein-Logik zur Verwendung abbildet und nichts über die Häufigkeit der Verwendung aussagt.
  • v$sql_plan: es ist teuer, diese View zu scannen - und ihre korrespondierenden Gegenstücke in AWR/Statspack basieren auf Sampling, so dass darin Queries fehlen können.
  • Analyse der Definitionen: durch Betrachtung der Index-Definitionen kann es bereits möglich sein, Redundanzen zu bestimmen und zu ermitteln, welche Indizes verzichtbar sein sollten. Natürlich kann dieses Vorgehen recht zeitaufwändig sein.
  • v$segstat, v$segment_statistics: liefern Informationen zu den Lese- und Schreiboperationen auf den Segmenten - wobei v$segment_statistics nur eine um Namen ergänzte Varainte von v$segstat darstellt. Weitere Details finden sich in der zugrunde liegenden Struktur x$ksolsstat. Die entscheidende Frage ist nun, wie man die darin enthaltenen Angaben sinnvoll interpretieren kann und zwischen der Arbeit, die im Rahmen der Index-Maintenance anfällt, und den eigentlichen Zugriffsoperationen unterscheidet - aber das ist eine Geschichte, die ein andermal erzählt werden soll; nämlich im angekündigten zweiten Artikel. 
Diesen zweiten Artikel plane ich zu ergänzen, aber das mag - urlaubsbedingt - einige Zeit dauern.

Keine Kommentare:

Kommentar veröffentlichen