Oracle 10g (Teil III):

Tanz den REORG

Reorganisation ist ein immer wiederkehrendes Thema bei Datenbanken und wird aus unterschiedlichen Gründen notwendig. Wichtig beim Durchführen von Reorganisationen sind Dauer und gegebenenfalls damit verbundene Einschränkungen für den Betrieb der Datenbank. In diesem Artikel stellen wir Ihnen zwei neue Features von Oracle 10g vor und zeigen deren Einsatzmöglichkeiten.

Die Features

Während dbms_redefinition schon in Oracle 9i vorhanden war, ist Segment Shrink ein neues Feature. dbms_redefinition wurde für Oracle 10g erweitert und hilft dem DBA bei der Reorganisation von Tabellen. Das Feature Segment Shrink wird bei der Reorganisation für die Defragmentierung von Segmenten genutzt.

Wichtigstes Merkmal beider Reorganisationspraktiken ist, dass sie online durchgeführt werden können, ohne dass ein exklusiver Tabellenzugriff gewährleistet sein muss.

Ausgangsstellung

Hauptgründe für die Reorganisation einer Tabelle sind meistens schlechter Blockfüllgrad und/oder migrierte Datensätze. Die Ursachen hierfür liegen z. B. bei einer zu geringen Oracle Blockgröße oder schlecht gewählten Storage Parametern bis hin zu stark flukturierenden Tabelleninhalten (ständige insert- und delete-Befehle). Dies sind nur einige Beispiele für die zuvor genannten Indizien. So wird mit der Zeit der Ruf nach Reorganisation immer lauter.

Step One: "Slow Fox – Ein langsamer Schritt, zwei Schnelle"

Folgende Möglichkeiten standen dem DBA für die Reorganisation bisher zur Verfügung:

1. Ex- und Import der Tabelle mit manueller Anpassung der Storageparameter
2. create table as select – Statement
3. alter table move – Statement
   
   Seit Oracle 9i wurden diese Möglichkeiten um eine vierte erweitert:
4. Der Einsatz des Packages dbms_redefinition

Die Möglichkeiten 1 - 3 setzen voraus, dass die Tabelle exklusiv für die Reorganisation zur Verfügung steht. Sprich: Parallel im Hintergrund laufende DML- oder DDL Statements müssen ausgeschlossen werden. Die vierte Möglichkeit wurde mit Oracle 9i eingeführt und hebt diese Einschränkung auf. Während der Reorganisation kann auf der zu reorganisierenden Tabelle ohne Einschränkungen weitergearbeitet werden. Das genaue Vorgehen hierbei führt uns zum nächsten Schritt.

Step Two: "Jive – Viele Schritte pro Takt"

Abbildung 1 zeigt das Vorgehen bis Oracle 9i beim Einsatz von dbms_redefinition. Zunächst wird eine leere Tabelle T1X erzeugt, die den gleichen Aufbau wie die zu reorganisierende Tabelle T1 besitzt. Dann wird über dbms_redefinition.start_redef_table automatisch eine Log-Tabelle erstellt, die alle parallel auftretenden DML Operationen auf der Tabelle T1 protokolliert.

Abb. 1: Vorgehen beim Einsatz von rdbms_redefinition bis Oracle 9i (vergrößern!).

Gleichzeitig wird damit begonnen, sämtliche Daten aus der Tabelle T1 in die Tabelle T1X zu kopieren. Hierfür muss natürlich ausreichend Speicherplatz im Tablespace vorhanden sein.

Als nächstes greift der Administrator ein, denn sämtliche Objekte, die von der Tabelle T1 abhängig sind, müssen nun manuell für die Tabelle T1X erstellt werden. Dies ist die größte Stolperfalle und gleichzeitig der Grund, weshalb viele DBAs diesen "Ausfallschritt" nicht setzen und stattdessen auf alte Methoden zurückgreifen. Durchaus verständlich, wenn man bedenkt, welcher Aufwand für eine Tabelle dabei betrieben werden muss: Feststellen, welche Objekte direkt von der Tabelle T1 abhängig sind, Erstellen dieser abhängigen Objekte (Synonyme, Trigger, Indizes, Grants) und Kontrolle der durchgeführten Arbeiten, um ja kein Objekt zu vergessen.

Sicherlich können Skripte und der Einsatz von dbms_metadata die Zeit verkürzen, aber der Aufwand für n-Tabellen ist weiterhin relativ hoch.

Diese Objekte müssen mit neuen Namen versehen werden, da die Namen eines Objekttyps im Schema eindeutig sein müssen.

Abschließend wird die Reorganisation über dbms_redefinition.finish_redef_table abgeschlossen. Hierbei werden die DML Operationen aus der Log-Tabelle nachgefahren und die Namen der zu reorganisierenden Tabelle (T1) und der reorganisierten Tabelle (T1X) getauscht. Hierfür wird für einen sehr kurzen Zeitraum ein DML-Lock auf beide Tabellen gesetzt. Anschließend kann die Tabelle T1X gelöscht werden. Damit ist die Reorganisation abgeschlossen.

Warum nicht automatisch?

Nun stellt sich berechtigterweise die Frage, aus welchem Grund Oracle nicht automatisch alle abhängigen Objekte erzeugt, damit der DBA an dieser Stelle nicht manuell eingreifen muss. Die Informationen hierfür stehen schließlich im Data Dictionary. Genau dies wird jetzt mit Oracle 10g ermöglicht: mit der Prozedur dbms_redefinition.copy_table_dependents

Diese Prozedur erstellt alle von einer Tabelle abhängigen Objekte und erleichtert so den Umgang mit dem Package dbms_redefinition um ein Vielfaches. Abbildung 2 zeigt nun die Abfolge der aufzurufenden Prozeduren unter Oracle 10g.

Abb. 2: Die Abfolge der aufzurufenden Prozeduren unter Oracle 10g (vergrößern!).

Step Three: "Quickstep – Schnelle, dynamische Bewegungen"

Eine weitere Möglichkeit, eine Online-Reorganisation vorzunehmen, ist das "Segment Shrink". Mit Hilfe von Segment Shrink können Daten in einer Tabelle verdichtet und die High Water Mark zurückgesetzt werden.

Voraussetzung für den Einsatz dieser neuen Technik ist die Verwendung von "Automatischem Segment Space Management", kurz ASSM (siehe ORDIX News 2/2003). Da bei dem Vorgang des Verdichtens die ROWIDs verändert werden, muss die entsprechende Tabelle über den Befehl ALTER TABLE tab ENABLE ROW MOVEMENT; hierfür vorbereitet werden. Für das Segment Shrink wurde der ALTER TABLE Befehl in der Syntax erweitert:

ALTER TABLE tab SHRINK SPACE COMPACT;
bzw.
ALTER TABLE tab SHRINK SPACE CASCADE;

Beide Befehle führen dazu, dass die Daten in vordere, nicht vollständig gefüllte Blöcke verdichtet werden. Im Falle von SPACE COMPACT bleibt die High Water Mark am alten Platz. Es werden also keine Extents freigegeben. Im Falle CASCADE wird die High Water Mark auf den tatsächlich letzten, belegten Block gesetzt. Frei gewordene Extents werden zurückgegeben. Die Funktionalität wird intern mittels Insert/Delete ohne Auslösen von Triggern durchgeführt (siehe Abbildung 3). Dieses wird durch ein implizites ALTER TABLE enable/disable all triggers gewährleistet.

Abb. 3: Unterschiede zwischen SHRINK COMPACT und SHRINK CASCADE (vergrößern!).

Was ist nun der Sinn der Funktionalität COMPACT ?

Bei ASSM wird bei einem Full Table Scan nur bis zur Low High Water Mark gelesen. Die High High Water Mark ist hier irrelevant. Die Low High Water Mark ist der tatsächlich letzte Block, also derselbe Block, wie im Falle CASCADE. COMPACT sollte also verwendet werden, wenn davon ausgegangen werden kann, dass der freie Platz in kurzer Zeit wieder belegt wird.

Fazit

Die Erweiterung von dbms_redefinition war überfällig und macht erst jetzt das Paket wirklich einsetzbar. Segment Shrink bietet eine neue, sehr einfache Möglichkeit, eine Tabelle zu defragmentieren. Beide Reorganisationspraktiken sind online durchführbar, um den Anwendern beim Reorg-Tanz nicht auf "die Füße zu treten".

Michael Lindermann (info@ordix.de).