Bild 2 zeigt einen normalen INSERT-Befehl auf die Tabelle "auftraege", aus der vorher ein oder mehrere Male größere Datenmengen gelöscht wurden. Zunächst erscheint es so, als ob das Auffüllen der Blöcke seinen Zweck erfüllt, da INSERT in alle teilweise oder vollständig leeren Blöcke Datensätze einfügt. Allerdings kann bei einer solchen Tabelle davon ausgegangen werden, dass die aktuellsten Aufträge am häufigsten gelesen werden. Die Verteilung dieser Aufträge auf immer mehr Blöcke, in denen auch "alte" Aufträge liegen, führt aber dazu, dass sich die Trefferrate im Cache und somit die Performance zusehends verschlechtert. In diesem Fall sollten Sie sofort nach dem Löschen der Sätze eine Reorganisation der Tabelle durchführen. Nur hierdurch stellen Sie eine hohe Trefferrate und damit eine Minimierung der Zugriffe auf die Platte sicher.


Bild 2: Auch die Leistung fressende Blockfragmentierung kann ein Grund für die Reorganisation von Datenbanken sein

Index-Reorganisation
Den größten Nutzen bei gleichzeitig minimiertem Aufwand bietet die Reorganisation von Indizes. In den meisten Fällen wird, zumindest in OLTP-Systemen (Online Transaction Processing) mit so genannten B*Tree Indizes gearbeitet, das heißt der Index ist immer ausbalanciert. Damit ist sichergestellt, dass der Zugriff auf jeden beliebigen Datensatz über den Index (Index Unique Scan) gleich viele Blöcke im Indexbaum lesen muss. Allerdings führt dies bei Indizes auf fortlaufende Nummern oder auf ein Datumsfeld (so es nicht das Geburtsdatum ist) dazu, dass der Indexbaum mit zunehmender Anzahl Sätze immer tiefer wird und die einzelnen Indexblöcke immer spärlicher mit Daten gefüllt sind. In diesem Fall bietet es sich an, derartige Indizes regelmäßig zu reorganisieren.

Im Übrigen wird oft behauptet, dass die Performance sich erheblich verbessert hätte, weil eine Tabelle reorganisiert wurde, die vorher mehrere hundert Extents hatte oder sich über zahlreiche Datendateien erstreckte. Erwiesenermaßen ist dies nicht beziehungsweise nur indirekt der Fall. Mit jeder Reorganisation einer Tabelle werden auch die zugehörigen Indizes reorganisiert. Daraus resultiert in jedem Fall eine Verbesserung der Performance, da der Indexbaum jetzt viel kompakter ist.

So sollten Sie reorganisieren
Am besten ist es, wenn Sie – abgesehen von den Indizes – gar nicht reorganisieren müssen. Wie beschrieben, gibt es einige Maßnahmen (etwa PCTFREE), die helfen können, eine Reorganisation zu vermeiden. Beim Archivieren und Löschen von Daten kann außerdem eine Partitionierung von Tabellen hilfreich sein. Dafür muss allerdings die entsprechende Partitioning Option lizenziert sein.

Sollte dennoch eine Reorganisation erforderlich sein, so muss diese gut geplant sein und sollte sich möglichst online durchführen lassen. Der Vorteil einer Online-Reorganisation liegt auf der Hand, da es sich in nahezu allen Fällen um eine kritische Datenbank handelt – denn andernfalls bräuchten Sie sich nicht mit dem Thema Reorganisation zu beschäftigen. Klassischerweise sind aber gerade bei kritischen Datenbanken die Wartungsfenster eher klein. Die Dauer einer Reorganisation ist zudem oft nur sehr schwer im Voraus zu kalkulieren. Im schlimmsten Fall kann es also sein, dass die Reorganisation noch nicht beendet ist, bevor die Anwendung wieder gestartet werden muss. Notwendigen Aktivitäten für eine Online-Reorganisation können Sie so während der normalen Arbeitszeit aufsetzen, was die Gefahr von Fehlern minimiert.

Online-Tabellen-Reorganisation
Generell sollte bei der Reorganisation einer Tabelle (egal ob online oder offline) immer das gleiche Verfahren verwendet werden. Legen Sie einen neuen Tablespace an und verschieben Sie die Tabelle in diesen Tablespace. Wenn Sie die Datenbank optimal geplant haben, das heißt jede kritische Tabelle über einen eigenen Tablespace verfügt, bedeutet dies, dass anschließend der alte Tablespace leer ist und Sie diesen löschen können.

Bei der Online-Reorganisation bauen Sie also eine zweite Tabelle auf und kopieren den aktuellen Datenbestand in diese Tabelle. Oracles "Read Consistency Model" garantiert, dass es einen klar definierten Startpunkt für den Kopiervorgang gibt, das heißt es werden keine Änderungen übertragen, die nach dem Start des Kopiervorgang durchgeführt wurden. Diese Änderungen werden in einer Logtabelle zwischengespeichert: Nutzen Sie Oracle Redefinition, ist diese Logtabelle ein Materialized View Log, bei der Reorganisations-Lösung Space Manager von Quest Software eine entsprechende Log-Tabelle.

Nachdem Sie die Kopie erstellt haben, können jetzt die Änderungen in mehreren Zyklen so lange nachgezogen werden, bis beide Tabellen den identischen Stand haben ("in Sync sind"). Jetzt benennen Sie Quell- und Zieltabelle um. Bei der Reorganisation mit Oracle Redefinition wird hierfür eine kurze Sperre benötigt. Quest Space Manager kann auf diese Sperre verzichten, wenn die Partitioning Option lizenziert wurde (was etwa im Umfeld von SAP Datenbanken der Fall ist). Außerdem erlaubt die Quest-Lösung auch das Reorganisieren von Tabellen, die den Datentyp LONG beziehungsweise LONG RAW verwenden. In jedem Fall ist es wichtig, dass Sie alle Constraints vor dem Umschalten bereits erstellt und aktiviert haben.

Alternativ bietet Oracle ab der Version 10g an, eine Tabelle mit dem Befehl SHRINK SPACE zu reorganisieren. Dies entspricht in etwa dem Defragmentieren beim Microsoft Betriebssystem, das heißt die Blöcke werden zusammengeschoben ("in-Place Reorganisation"). Der Vorteil ist, dass kein zusätzlicher Platz benötigt wird, allerdings ist dieses Verfahren fehleranfälliger und langsamer. In den meisten Fällen ist also eine "out-of-Place"-Reorganisation vorzuziehen.

Online-Index-Reorganisation
Wenn nur der Index reorganisiert werden soll, verwenden Sie am einfachsten der Befehl ALTER INDEX REBUILD mit der Option ONLINE. In diesem Fall wird basierend auf dem existierenden Index ein zweiter aufgebaut. Nachdem dieser erstellt wurde, werden die Indexnamen getauscht und der neue Index steht zur Verfügung. Auch bei der Index-Reorganisation ist es ratsam, den Index während der Reorganisation in einen neuen Tablespace zu verschieben, da sich hierdurch eine Fragmentierung in dem Tablespace vermeiden lässt.

Fazit
Zwar gibt es immer noch Gründe für eine Reorganisation, allerdings können Sie bei geeigneter Planung (Stichwort Kapazitätsplanung) zumindest die Tabellen-Reorganisation in vielen Fällen vermeiden. Die Überwachung der Indizes bezüglich des Bedarfs einer Reorganisation sollte jedoch zum Standardrepertoire eines DBAs gehören. Einfache Werkzeuge, wie der bereits genannte Space Manager oder auch der Toad von Quest Software, können bei der Planung und Durchführung von Reorganisationen nützlich sein.

         <<Vorherige Seite                          Seite 2 von 2

ln/Johannes Ahrends, Technical Director Application und Database Management, Quest Software GmbH