Eine große Tabelle umstrukturieren, während Anwendungen weiterarbeiten: Dafür bietet Oracle Database die Online-Redefinition über DBMS_REDEFINITION. Die Daten werden in eine Interim-Tabelle übertragen, während Änderungen an der Ursprungstabelle nachgeführt werden. Am Ende werden die Tabellen in einer kurzen, aber notwendigen Umschaltphase vertauscht. „Online“ bedeutet daher nicht „ohne jede Sperre“ – die Planung des Cutovers bleibt entscheidend.
1. Eignung vor dem Start prüfen
Beginnen Sie mit CAN_REDEF_TABLE. Wählen Sie nach Möglichkeit die Redefinition über Primärschlüssel; dafür muss die geeignete Schlüsseldefinition erhalten bleiben. Die Rowid-Methode ist eine Alternative, wenn kein passender Schlüssel existiert, aber nicht für Index-Organized Tables. Prüfen Sie außerdem Tablespace, Speicherbedarf für die Interim-Tabelle, erforderliche Berechtigungen und die Auswirkungen auf Abhängigkeiten.
BEGIN
DBMS_REDEFINITION.CAN_REDEF_TABLE(
uname => 'APP',
tname => 'ORDERS',
options_flag => DBMS_REDEFINITION.CONS_USE_PK
);
END;
/2. Interim-Tabelle und Abhängigkeiten vorbereiten
Erstellen Sie eine leere Interim-Tabelle mit der gewünschten Zielstruktur. Danach starten Sie START_REDEF_TABLE mit Spaltenzuordnung und passender Methode. COPY_TABLE_DEPENDENTS hilft, abhängige Objekte wie Indizes, Trigger, Constraints und Berechtigungen zu übernehmen. Prüfen Sie die zurückgemeldeten Fehler ausdrücklich: Ein erfolgreicher Kopiervorgang ist kein Ersatz dafür, die erwarteten Objekte mit dem Zielzustand abzugleichen.
Besondere Aufmerksamkeit brauchen unter anderem Fremdschlüssel, Materialized-View-Logs, Statistiken und VPD-Richtlinien. Die Interim-Tabelle ist nicht einfach eine beliebige temporäre Kopie, sondern wird später zum Objekt unter dem ursprünglichen Tabellennamen.
3. Synchronisieren und Cutover kontrollieren
Während die Kopie läuft, kann DML auf der Ursprungstabelle weitergehen. Bei längeren Läufen oder hoher Änderungsrate synchronisiert SYNC_INTERIM_TABLE die Interim-Tabelle vorab. Das reduziert typischerweise die noch nachzuholende Arbeit beim Abschluss. Beobachten Sie Dauer, DML-Last, Speicherverbrauch und Fehlerzustände; planen Sie den Abschluss nicht erst, wenn das Wartungsfenster bereits läuft.
FINISH_REDEF_TABLE führt den Cutover aus. Dabei wird die Ursprungstabelle kurz exklusiv gesperrt und auf ausstehende DML-Transaktionen gewartet. Mit dml_lock_timeout lässt sich begrenzen, wie lange der Aufruf wartet; bei einem Timeout kann der Abschluss erneut gestartet werden. Testen Sie diesen Ablauf unter realistischer Last und halten Sie einen Abbruch- und Wiederanlaufplan bereit.
4. Aufräumen erst nach Prüfung
Nach dem Wechsel prüfen Sie Spalten, Constraints, Grants, Trigger, Indizes, Statistiken und Anwendungspfade. Die Interim-Tabelle enthält danach die alte Tabellenversion. Löschen Sie sie erst, wenn keine relevanten Abfragen mehr darauf laufen und Sie die neue Struktur fachlich bestätigt haben. Bei einem fehlgeschlagenen Start muss der Redefinitionsvorgang kontrolliert mit ABORT_REDEF_TABLE bereinigt werden.
- Vorab Restore- und Rückfallstrategie sowie benötigten Zusatzspeicher verifizieren.
- CAN_REDEF_TABLE, Schlüsselwahl und Ziel-DDL in einer Testumgebung validieren.
- Abhängigkeiten, Fehlerzähler und Zwischensynchronisierung protokollieren.
- Cutover mit Lock-Timeout und realistischer DML-Last testen.
- Nach dem Wechsel Anwendungen prüfen und alte Interim-Tabelle erst später entfernen.
Fazit
DBMS_REDEFINITION kann große Strukturänderungen mit deutlich kleinerem Ausfallfenster ermöglichen. Der Erfolg hängt jedoch von vollständig geprüften Abhängigkeiten, rechtzeitiger Synchronisierung und einem beherrschten Cutover ab. Wer die Sperrphase und den Rückfallweg realistisch testet, macht aus der Online-Redefinition einen planbaren Betriebsprozess.
Weiterführend: Oracles Administrator’s Guide zur Online-Redefinition und die PL/SQL-Referenz zu DBMS_REDEFINITION.