Die Schlüssel-Reorganisation im Detail

Nach dem Anlegen eines neuen Schlüssels oder der Änderung eines bestehenden Schlüssels (Attribute oder Schlüsselfelder) ist ein Neuaufbau des Index notwendig – heute wollen wir diesen als Reorganisation bezeichneten Vorgang näher betrachten, der im übrigen komplett vom Datenbankserver ausgeführt wird.

Bei einer Veränderung eines Schlüssels muss vor der Generierung der neuen Schlüsselwerte zunächst das Löschen des bisherigen Index erfolgen. Dabei werden in der Datenbank zuerst die Wurzel und die Knotensegmente der Baumstruktur gelesen und gelöscht. Bei dieser Operation entstehen zwar Random-Zugriffe in die Datenbank, jedoch werden weniger als 1% des Index auf diese Weise verarbeitet. Beim Lesen dieser Segmente wird ein Verzeichnis aller Blattsegmente erstellt – diese enthalten die eigentlichen Schlüsselwerte und machen über 99% des Index aus. Alle Blattsegmente werden anschließend sortiert und in der Reihenfolge ihrer Segmentnummern gelesen und gelöscht. Dadurch besteht dieser Vorgang zum größten Teil aus sequentiellen Datenbankzugriffen und ermöglicht eine wesentliche höhere Löschgeschwindigkeit. Insbesondere bei Tabellen mit vielen Datensätzen und langen Schlüsselwerten kann der Löschvorgang trotzdem mehrere Minuten dauern. In dieser Zeit bleibt die Anzeige des Reorganisationsfortschritts unverändert.

Für die nachfolgende Generierung der neuen Schlüsselwerte benutzt der Datenbankserver zwei verschiedene Strategien. Bei weniger als 1000 Datensätzen wird ein weiterer Thread im Datenbankprozess gestartet, der diese Aufgabe übernimmt. Dabei werden nacheinander alle Datensätze der Tabelle in der Reihenfolge ihrer RecIDs gelesen und entpackt. Für jeden Datensatz wird der neue Schlüsselwert generiert und in den Indexbaum eingefügt. Der laufende Benutzerthread erledigt die Kommunikation mit dem Client, um die Anzeige des Fortschritts und einen eventuellen Abbruch der Reorganisation zu ermöglichen.

Diese Strategie erzeugt bei sehr großen Tabellen mit mehreren Millionen Datensätzen eine hohe I/O-Last, die fast ausschließlich aus Random-Zugriffen besteht. Dementsprechend lange würde ein Reorganisationslauf dauern. Enthält die Tabelle mehr als 1000 Sätze, wählt der Server daher eine aufwendigere Verarbeitung.

Der erste Schritt besteht aus dem Anlegen eines Segmentverzeichnis für alle Datensätze der Tabelle. Mit Hilfe dieses Verzeichnis kann dann ein eigener Thread alle Datensätze der Tabelle in aufsteigender Segmentreihenfolge lesen. Hierbei finden überwiegend sequentielle Zugriffe statt. Für jeden gelesenen Satz generiert der Thread den neuen Schlüsselwert und legt ihn in einem Puffer im Hauptspeicher ab. Ein weiterer Thread liest die Schlüsselwerte aus diesem Puffer und fügt sie in den Indexbaum ein. Diese Aufgabenteilung erhöht ebenfalls die Reorganisationgeschwindigkeit.

Die wichtigste Voraussetzung für eine schnelle Reorganisation ist jedoch eine ausreichende Menge an Datenbankpuffer. Reicht der Cache nicht für den gesamten Indexbaum aus, bricht die Geschwindigkeit mit zunehmender Dauer ein, der Lauf wird sichtbar immer langsamer. Vor größeren Reorganisationen sollten die Einstellungen daher auf eine ausreichende Cachegröße hin überprüft werden.

Beim Neuaufbau mehrerer Schlüssel einer Tabelle, werden diese nacheinander generiert. Falls alle Datensätze der Tabelle in den Datenbankpuffer passen, reduziert das die Dauer für den zweiten und alle weiteren Schlüssel.