News
DBA-Tipp: Daten und Tabellen online restrukturieren mit dem Feature "Online Redefinition"

Die Information ist ein schnelllebiges Gut. Jeden Tag werden wir mit hunderten Informationen zugemüllt. Deshalb sind wir bestrebt uns auf das Wesentliche zu konzentrieren und nur substantiell nachhaltige Informationen bereitzustellen.

Icon Unternehmen

Im Rahmen der täglichen DBA-Arbeiten fallen zuweilen Anforderungen an, Änderungen an Daten oder Tabellenstrukturen vorzunehmen, die aufgrund ihrer Natur oder der vorliegenden Datenmenge eine längere Downtime oder zumindest eine deutliche Beeinträchtigung des Betriebes mit sich bringen würden. Für die Erledigung solcher Aufgaben steht in der Enterprise Edition das Feature „Online Redefinition“ zur Verfügung, dessen Arbeitsweise in diesem DBA-Tipp kurz erläutert werden soll.

Anwendungsfälle

Die Erfordernisse für ein Reorganisieren oder Restrukturieren einer Tabelle sind vielfältig. Einige davon können vollkommen transparent erfolgen, andere beeinträchtigen zumindest den Betrieb vorübergehend, dritte bedingen eine echte Downtime:

  • Änderung eines Spaltentyps oder Löschen einer Spalte – Während der DDL-Operation wird die betroffene Tabelle gegen Schreibzugriffe gesperrt. Bei Tabellen mit hinreichend großer Zeilenzahl kann das eine Anwendung inakzeptabel lang beeinträchtigen.
  • Wechsel der Tabellenorganisation von partitioniert in unpartitioniert oder umgekehrt bzw. Änderung der Partitionierungsmethode – Diese Operationen wären nur per Export/Import oder „insert as select“ durchführbar. In beiden Fällen bedeutet das eine Downtime für die Anwendung.
  • Sortierte Speicherung der Daten zur Verringerung des clustering factors eines Indexes – Auch das ist ohne Redefinition nur durch „insert as select“ durchführbar und damit mit einer Downtime verbunden.
  • Shrinken von Datafiles – Während die Defragmentierung von Tabellen und Indizes mittlerweile mittels der shrink-Funktion komplett online und transparent erfolgen kann, erfordert das Shrinken von Datafiles nach wie vor ein „alter table move“, um Tabellenobjekte und damit letztlich die High-Water-Mark in Richtung Datafilebeginn zu verschieben. Zwar kann das Bewegen der Tabelle selbst auch online erfolgen. Die auf der Tabelle definierten Indizes werden allerdings mit dem Verschieben unusable und müssen mit rebuild neu erstellt werden. Bis zum Abschluss des Rebuild (der zudem nur in der Enterprise Edition online erfolgen kann) dürfte zumindest die Performance leiden. Im schlimmsten Fall kann das vorübergehende Fehlen der an Indizes gebundenen primary-key- oder unique-Constraints sogar logische Inkonsistenzen in der Datenbank verursachen.

Verfahrensweise

Die einzelnen Schritte für ein Online Redefinition sind folgende:

  1. Prüfen der Ausgangstabelle – Mittels DBMS_REDEFINITION.CAN_REDEF_TABLE prüft man optional, ob die in Frage stehende Tabelle die Voraussetzungen für ein Redefinition erfüllt. Auch für Online Redefinition gibt es einige verhindernde Einschränkungen. In der Praxis trifft man aber tendenziell eher selten darauf.
  2. Anlegen einer Interimstabelle – Diese Tabelle entspricht in ihrer Struktur (Spaltenzahl, -folge, -namen, -typen, Partitionierung, Tablespace etc.) dem gewünschten Zielzustand. Der Name der Tabelle ist irrelevant. Er wird am Ende des Redefinition durch den Namen der Ausgangstabelle ersetzt.
  3. Starten des Redefinition – Die Procedure DBMS_REDEFINITION.START_REDEF_TABLE initiiert das Redefinition. Im Detail bedeutet es, dass die Ausgangstabelle in den Redefintionstatus versetzt wird (der keine weitere Bedeutung hat, als dass sie jetzt in keiner weiteren Redefinition verwendet werden kann und dass einkommende Datenänderungen gepuffert und später noch auf die Interimstabelle synchronisiert werden) und alle Daten der Ausgangstabelle in die Interimstabelle kopiert werden. In diesem Schritt erfolgt damit die eigentliche Redefinition, also zum Beispiel Defragmentierung, Sortierung, Spaltenmapping oder Partitionierung/De-Partitionierung. Auch wenn sich die betreffende Tabelle im Redefinitionstatus befindet (und im Hintergrund ihre Daten in die Interimstabelle kopiert werden), sind SELECT und DML weiterhin uneingeschränkt möglich.
  4. Nach dem Abschluss des START_REDEF_TABLE ist nun die Beziehung zwischen Ausgangs- und Interimstabelle hergestellt und der Datenstand zwischen den beiden Tabellen initial abgeglichen. In einem weiteren Schritt können nun noch alle abhängigen Objekte der Ausgangstabelle, also Privilegien, Constraints, Trigger, Statistiken und Indizes, an die Intermstabelle kopiert werden. Hierzu verwendet man DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS. Auch hier werden für die abhängigen Objekte vorerst systemgenerierte Namen verwendet, die am Ende des Redefinition automatisch durch die Namen der korrespondierenden Objekte der Ausgangstabelle ersetzt werden. Es ist also nach Abschluss des Redefinition sichergestellt, dass zum Beispiel benannte Indexhints oder SQL-Profile, aber auch referentielle Integritäten, weiterhin greifen und „sprechende“ Namen erhalten bleiben.
  5. Sowohl in Schritt 4 als auch 5 sollte der DBA natürlich verstärkt auf das Archivelogaufkommen achten. Beide Schritte erzeugen im Hintergrund klassisches DML/DDL und damit u.U. entsprechend viel Redoinformationen.
  6. Sind die abhängigen Objekte fertig synchronisiert, könnte das Redefinition grundsätzlich abgeschlossen werden. Alle Änderungen, die seit dem Start des Redefinition (mit START_REDEF_TABLE) aufgelaufen sind, wurden zwischenzeitlich gepuffert. Dieser Puffer kann (und sollte insbesondere falls Kopieren der Daten oder abhängigen Objekte lange gedauert haben) mittels DBMS_REDEFINITION.SYNC_INTERIM_TABLE abgeglichen werden.
  7. Mit einem abschließenden DBMS_REDEFINITION.FINISH_REDEF_TABLE wird das Redefinition schließlich beendet. Lediglich an diesem Punkt werden Ausgangs- und Interimstabelle für einen kurzen Augenblick gesperrt. In diesem Schritt werden noch letzte Daten übertragen und abschließend die Namen zwischen Ausgangs- und Interimstabelle sowie allen abhängigen Objekten ausgetauscht. Unmittelbar danach steht die in Schritt 2 erzeugte Interimstabelle nun mit reorganisierten Daten oder veränderter Struktur unter dem Namen der ursprünglichen Ausgangstabelle zur Verfügung. Alle Anwendungen, die bisher auf die Ausgangstabelle zugriffen, greifen nun ohne den geringsten Anpassungsaufwand auf die redefinierte Tabelle zu.

Fazit

Das Oracle Enterprise Edition Feature „Online Redefinition“ erlaubt eine (praktisch) unterbrechungs- und störungsfreie Reorganisation oder Redefinition von Tabellen, die unter andern Umständen (z.B. in einer Oracle Standard Edition) nur unter erheblichen Beeinträchtigungen bis hin zur kompletten Downtime der Anwendung möglich wären. Dabei ist nicht nur eine reine Redefinition der Tabellenstruktur möglich, sondern auch performance- oder platzrelevante Wartungsarbeiten wie Defragmentierung und Verschieben von Daten. Die Redefinition bleibt über ihre gesamte Laufzeit von START_REDEF_TABLE bis FINISH_REDEF_TABLE nach außen vollkommen transparent.