von Redaktion IT-A…
Lesezeit
2 Minuten
Reorganisation von Oracle-Datenbanken
Im Oracle-Umfeld wird das Thema Reorganisation von Objekten - sowohl was Tabellen als auch was Indizes angeht - seit vielen Jahren kontrovers diskutiert. Dieser Fachartikel geht der Frage nach, aus welchen Gründen überhaupt reorganisiert werden muss, und beschreibt, welche Werkzeuge sich dafür nutzen lassen. Dabei stehen insbesondere die Themen Offline- oder Online-Reorganisation und die schnelle Reorganisation von Objekten oder ganzen Gruppen im Vordergrund.
Es klingt zunächst logisch, dass nicht mehr benötigte Bereiche der Datenbank wieder freigegeben werden. In der Praxis wachsen Datenbanken allerdings kontinuierlich, "nicht mehr benötigter Platz" ist eher selten. Dennoch lohnt es sich, freie Bereiche im Auge zu behalten: Denn diese vergrößern unter Umständen auch den benötigten Platz für eine Sicherung der Datenbank und verlängern damit Backup- und Recovery-Zeiten. Außerdem lässt sich durch einen optimalen Zugriff auf die Daten die Performance verbessern. Dies ist dann der Fall, wenn möglichst gar kein physikalisches Lesen notwendig ist, sondern sich die benötigten Daten bereits im Cache befinden.
Performanceoptimierung bedeutet also, ähnlich wie bei der Defragmentierung unter Windows, dass Daten zusammengeschoben werden. Allerdings ist eine Oracle-Datenbank doch wesentlich komplexer als die Datenspeicherung auf einem PC, wodurch sich eine andere Vorgehensweise bei der Reorganisation ergibt.
Gründe für eine Reorganisation
Tabellen-Reorganisation
Tabellen sollten dann reorganisiert werden, wenn es Row Chaining in Form von Migrated Rows gibt oder wenn durch das Löschen einer Menge von Sätzen die Blöcke nur noch partiell gefüllt sind. Von Migrated Rows spricht man, wenn ein Datensatz in einem Oracle-Block vergrößert werden soll, weil beispielsweise ein ursprünglich leeres Feld durch ein Update mit einem Wert gefüllt wird, in dem Block aber kein freier Platz mehr zur Verfügung steht. Standardmäßig werden zwar in jedem Block zehn Prozent (PCTFREE) Platz für Erweiterungen durch Updates frei gelassen, speziell bei Massenupdates reicht dieser Platz aber nicht aus. Der zu vergrößernde Satz wird in einen anderen Block verschoben, die zugehörigen Indexeinträge verweisen aber weiterhin auf den alten Block (siehe Bild 1). Da die Datenbank bei jedem Zugriff über den Index zunächst den "falschen" Block lesen muss, verschlechtert sich die Performance beim Zugriff auf diese Sätze.
Bild 1: "Migrated Rows" – die Auslagerung von Werten in einen separaten Block – verschlechtern die Zugriffszeiten
Wenn Sie bei einer Anwendung damit rechnen müssen, dass die Länge der Datensätze sich im Laufe der Zeit vergrößert, sollten Sie den Parameter PCTFREE entsprechend anpassen. Dies ist beispielsweise typisch für Workflow-Systeme, bei denen zunächst wenige Informationen in der Tabelle gespeichert, im Anschluss aber immer mehr Daten hinzugefügt werden. Die Parameter-Anpassung lässt sich auch vornehmen, wenn die Tabelle bereits existiert, betrifft dann jedoch nur neue Blöcke.
Wichtig ist es, die Migrated Rows nicht mit dem eigentlichen Row Chaining zu verwechseln, das dann auftritt, wenn sich ein Datensatz über mehrere Oracle-Blöcke erstreckt (also mehrere Blöcke verkettet sind). Dies ist vor allem dann der Fall, wenn Sie den Datentyp LONG beziehungsweise LONG RAW verwenden, da hier die Feldgröße bis zu 2 GByte betragen kann – logisch, dass dies nicht in einen Oracle-Block von 8 KByte passt. Auch wenn Sie die Tabelle mit mehr als 255 Spalten definiert haben, findet eine Verteilung der Sätze über mehrere Blöcke statt, unabhängig davon, wie groß die einzelnen Spalten sind. Eine derartige Tabelle zu reorganisieren wäre nutzlos, da die Struktur nicht geändert wird.
Wenn große Mengen an Daten archiviert und anschließend in der Tabelle gelöscht werden, entstehen Lücken beziehungsweise der Füllgrad der einzelnen Oracle-Blöcke kann stark variieren. Auch wenn Oracle seit der Version 10 das so genannte Automatic Segment Space Management (ASSM) anbietet, das dafür sorgt, dass die einzelnen Blöcke immer möglichst optimal gefüllt werden, kann dies zu einem Problem werden.
ln/Johannes Ahrends, Technical Director Application und Database Management, Quest Software GmbH
Performanceoptimierung bedeutet also, ähnlich wie bei der Defragmentierung unter Windows, dass Daten zusammengeschoben werden. Allerdings ist eine Oracle-Datenbank doch wesentlich komplexer als die Datenspeicherung auf einem PC, wodurch sich eine andere Vorgehensweise bei der Reorganisation ergibt.
Gründe für eine Reorganisation
Tabellen-Reorganisation
Tabellen sollten dann reorganisiert werden, wenn es Row Chaining in Form von Migrated Rows gibt oder wenn durch das Löschen einer Menge von Sätzen die Blöcke nur noch partiell gefüllt sind. Von Migrated Rows spricht man, wenn ein Datensatz in einem Oracle-Block vergrößert werden soll, weil beispielsweise ein ursprünglich leeres Feld durch ein Update mit einem Wert gefüllt wird, in dem Block aber kein freier Platz mehr zur Verfügung steht. Standardmäßig werden zwar in jedem Block zehn Prozent (PCTFREE) Platz für Erweiterungen durch Updates frei gelassen, speziell bei Massenupdates reicht dieser Platz aber nicht aus. Der zu vergrößernde Satz wird in einen anderen Block verschoben, die zugehörigen Indexeinträge verweisen aber weiterhin auf den alten Block (siehe Bild 1). Da die Datenbank bei jedem Zugriff über den Index zunächst den "falschen" Block lesen muss, verschlechtert sich die Performance beim Zugriff auf diese Sätze.
Bild 1: "Migrated Rows" – die Auslagerung von Werten in einen separaten Block – verschlechtern die Zugriffszeiten
Wenn Sie bei einer Anwendung damit rechnen müssen, dass die Länge der Datensätze sich im Laufe der Zeit vergrößert, sollten Sie den Parameter PCTFREE entsprechend anpassen. Dies ist beispielsweise typisch für Workflow-Systeme, bei denen zunächst wenige Informationen in der Tabelle gespeichert, im Anschluss aber immer mehr Daten hinzugefügt werden. Die Parameter-Anpassung lässt sich auch vornehmen, wenn die Tabelle bereits existiert, betrifft dann jedoch nur neue Blöcke.
Wichtig ist es, die Migrated Rows nicht mit dem eigentlichen Row Chaining zu verwechseln, das dann auftritt, wenn sich ein Datensatz über mehrere Oracle-Blöcke erstreckt (also mehrere Blöcke verkettet sind). Dies ist vor allem dann der Fall, wenn Sie den Datentyp LONG beziehungsweise LONG RAW verwenden, da hier die Feldgröße bis zu 2 GByte betragen kann – logisch, dass dies nicht in einen Oracle-Block von 8 KByte passt. Auch wenn Sie die Tabelle mit mehr als 255 Spalten definiert haben, findet eine Verteilung der Sätze über mehrere Blöcke statt, unabhängig davon, wie groß die einzelnen Spalten sind. Eine derartige Tabelle zu reorganisieren wäre nutzlos, da die Struktur nicht geändert wird.
Wenn große Mengen an Daten archiviert und anschließend in der Tabelle gelöscht werden, entstehen Lücken beziehungsweise der Füllgrad der einzelnen Oracle-Blöcke kann stark variieren. Auch wenn Oracle seit der Version 10 das so genannte Automatic Segment Space Management (ASSM) anbietet, das dafür sorgt, dass die einzelnen Blöcke immer möglichst optimal gefüllt werden, kann dies zu einem Problem werden.
Seite 1 von 2 Nächste Seite>>
ln/Johannes Ahrends, Technical Director Application und Database Management, Quest Software GmbH
