Oracle 9i New Features:

DBMS_REDEFINITION

Vierundzwanzig mal sieben. Darunter versteht man die Anforderung an ständige Verfügbarkeit eines Systems, auch der Datenbank. Dennoch ist manche Datenpflege bisweilen nicht im Betrieb des Systems möglich, ohne die Anwender zu behindern. Ein Beispiel dafür ist die sogenannte Reorganisation von Tabellen. Nicht so unter der Version Oracle 9i. Wartezeiten „wegen notwendiger Datenpflege“ gehören nun definitiv der Vergangenheit an. Denn DBMS_REDEFINITION ermöglicht es Ihnen, Tabellen samt der darin enthaltenen Daten innerhalb der Datenbank zu reorganisieren; und zwar zur besten Kernzeit und ohne Behinderung der mit der Datenbank arbeitenden Online- oder Batch-Applikationen.

Datenbanken leben von und mit der Dynamik der Daten. Wächst das Datenvolumen, insbesondere in einzelnen Tabellen, sehr stark an, so kann die Handhabung der Datenbank und die Performance der Applikationen beeinträchtigt werden. Mit der Version 9i stellt Oracle das PL/SQL Package DBMS_REDEFINITION vor, mit dem Tabellen umgeformt werden können. Dabei ist es nicht nur möglich, die Struktur der Tabelle und deren physikalische Parameter umzustellen, sondern diese Aktion kann auch noch während des Betriebs durchgeführt werden.

Szenario für die Redefinition von Tabellen

Seit der Version 8i besteht die Möglichkeit, mit dem Befehl ALTER TABLE ... MOVE TABLESPACE Tabellen zu reorganisieren. Dabei wird die Tabelle unter Beibehaltung ihrer Constraints, Trigger, etc. sowie samt ihrer Inhalte innerhalb des bestehenden Tablespace oder in einem anderen Tablespace neu aufgebaut. Einen Nebeneffekt dieser Aktion muss man leider in Kauf nehmen: Während der gesamten Ausführungszeit des Befehls besteht eine exklusive Sperre auf der gesamten Tabelle. Diese Art der Reorganisation nennen wir deshalb offline Reorganisation, denn sie benötigt ein Wartungsfenster.

Abb. 1: Reorganisation einer Tabelle während des Betriebs.

Oracle legt nun in der Version 9i (nur Enterprise Edition und Personal Edition) eine Erweiterung dieser Technologie nicht als Statement sondern in Form eines PL/SQL-Packages vor. Nach der neuen Terminologie kann die Tabelle damit nicht nur reorganisiert, sondern auch redefiniert werden. Zahlreiche Modifikationen sind möglich, darunter

• Transformation der Tabelle in eine partitionierte, indexorientierte oder heap-orientierte Tabelle,
• Hinzufügen, Entfernen oder Modifizieren von Spalten.

Im Folgenden wollen wir den Einsatz dieser Technologie mit Hilfe eines Beispiels erläutern: Das Volumen der Tabelle BESTELLUNG ist in kurzer Zeit weit über die ursprüngliche Abschätzung hinaus angewachsen. Hinzugekommen ist die Zusammenführung der Daten sämtlicher Filialen mit umfangreichem Alt- und Neudatenbestand. Nach der Datenübernahme kann das System die Datenmenge kaum noch bewältigen, die Bearbeitung der Datensätze sowie die Rechnungsläufe fordern immer mehr Laufzeit. Sie beschließen eine Tabellenreorganisation: Die Tabelle soll zur besseren Handhabung und Performancesteigerung partitioniert werden. Es steht dafür kein Wartungsfenster zur Verfügung. Die Umstellung soll so bald wie möglich durchgeführt werden.

DBMS_REDEFINION

Das Package DBMS_REDEFINITION liefert die notwendigen Prozeduren. Der Ablauf erfordert Ihre Mitwirkung und einiges an Vorbereitung.

DBMS_REDEFINITION.CAN_REDEF_TABLE (
  uname	IN VARCHAR2,	-- Schema
  tname	IN VARCHAR2);	-- Tabelle

1. Prüfen Sie, ob es technisch möglich ist, die Tabelle BESTELLUNG zu reorganisieren. Das Package stellt nämlich Kriterien zur Verfügung, die erfüllt sein müssen. Unsere Tabelle kann nicht mit dem Package reorganisiert werden, wenn zum Beispiel:

   • kein Primary Key vorhanden ist, oder
   • Materialized Views oder Materialized View Logs auf Basis der Tabelle definiert sind, oder
   • die Tabelle Spalten vom Typ FILE, LONG und nicht unterstützte Typdefinitionen (objects, REFs, collections, typed tables) enthält.

   Die vollständige Liste der Einschränkungen finden Sie in Abb. 7.

   Prüfen Sie mittels der Prozedur CAN_REDEF_TABLE(), ob die Tabelle BESTELLUNG die Kriterien erfüllt. Ist das nicht der Fall, erhalten Sie eine Begründung in Form einer Fehlermeldung. Bringt dagegen die Prozedur keine Ausgabe hervor, so sind die geprüften Kriterien erfüllt. Für das Beispiel wird angenommen, dass die besagte Tabelle im Schema FIBU installiert ist.

2. In unserem Beispiel der Redefinition einer Tabelle handelt es sich im gleichen Zuge um die Partitionierung der Tabelle. Nachdem die Kriterienprüfung positiv ausgefallen ist, erstellen Sie eine Interimstabelle, die Sie z. B. BESTELLUNG_2 nennen. Voraussetzung ist, dass sich BESTELLUNG und BESTELLUNG_2 im gleichen Schema befinden. Erstellen Sie alle Constraints, Trigger und Indizes auf die Interimstabelle, aber halten Sie sie bis zum Ende der Datenübernahme abgeschaltet. Geben Sie schließlich alle Zugriffsrechte auf die Interimstabelle. Am Ende der Umformung wird die Interimstabelle BESTELLUNG_2 die Datensätze der Tabelle BESTELLUNG enthalten.

   DBMS_REDEFINITION.START_REDEF_TABLE ( uname IN VARCHAR2, orig_table IN VARCHAR2, int_table IN VARCHAR2, col_mapping IN VARCHAR2 := NULL);

   Abb. 3: Syntax zur Initialisierung der Reorganisation der Tabelle BESTELLUNG.

   
   

3. Die Reorganisation kann nun durchgeführt werden. Rufen Sie zunächst die Prozedur START_REDEF_TABLE() (Abb. 3) auf. Die ersten drei Übergabeparameter sind aus der vorangegangenen Prozedur bekannt: der Name des Schemas, gefolgt von den beiden Tabellen. Ein weiterer Parameter ist optional und kann genutzt werden, wenn im Zuge der Reorganisation auch einzelne Spalten modifiziert werden. Soll z. B. die Spalte B_Nr und K_ID in Bestellung_nr und Kunden_nr umbenannt werden, so lautet in diesem Fall der vierte Übergabeparameter: ‘b_nr Bestellung_nr, k_id Kunden_nr‘.

   DBMS_REDEFINITION.SYNC_INTERIM_TABLE ( uname IN VARCHAR2, orig_table IN VARCHAR2, int_table IN VARCHAR2);

   Abb. 4: Syntax zur Synchronisation der Datenbestände.

   
   

4. Jetzt rufen Sie die Prozedur SYNC_INTERIM_TABLE() auf, um den Datenbestand der Tabelle BESTELLUNG in die Tabelle BESTELLUNG_2 zu übernehmen. Diese Synchronisation ist optional und kann beliebig oft wiederholt werden. Sie dient dazu, die Laufzeit des abschließenden Schrittes zu verkürzen. Es ist sinnvoll, die Synchronisation durchzuführen, wenn zwischen Initialisierung und Abschluss der Reorganisation eine längere Zeit verstrichen ist und Massendaten in die Tabelle aufgenommen wurden.

   DBMS_REDEFINITION.FINISH_REDEF_TABLE ( uname IN VARCHAR2, orig_table IN VARCHAR2, int_table IN VARCHAR2);

   Abb. 5: Syntax zum Abschluss der Reorganisation der Tabelle.

   
   

5. Rufen Sie die Prozedur FINISH_REDEF_TABLE() auf. Diese Prozedur vervollständigt die Übernahme des Datenbestands und lässt schließlich die beiden Tabellen ihre Namen tauschen. Lediglich in der Endphase und nur für eine kurze Zeit wird die Tabelle gesperrt und danach wieder freigegeben.

6. Die Tabellenreorganisation ist erfolgreich durchgeführt. Sie müssen nur noch die Constraints aktivieren. Die Tabelle BESTELLUNG erscheint in ihrer neuen Form, während die Tabelle BESTELLUNG_2 in die Ablage geschoben werden kann.

Das Package bietet als weitere Hilfe die Prozedur ABORT_REDEF_TABLE. Diese Prozedur ist dann aufzurufen, wenn die Reorganisation nach der Initialisierungsphase abgebrochen werden muss.

DBMS_REDEFINITION.ABORT_REDEF_TABLE (
  uname		IN VARCHAR2,
  orig_table	IN VARCHAR2,
  int_table	IN VARCHAR2);

Fazit

Mit dem Package DBMS-Redefinition wird die Verfügbarkeit der Datenbank erhöht. Dennoch ist die Liste der Restriktionen noch sehr lang. Die Möglichkeit zur Redefinition der Tabellen eines Clusters oder die Unterstützung von benutzerdefinierten Datentypen wären schon wünschenswert.

Ferner wäre eine Unterstützung bei der Übernahme der an die Tabelle gekoppelten Objekte wie Trigger, Constraints, Indizes etc. hilfreich. Speziell in Verbindung mit diesen Objekten ist die generelle Problematik der in einem Schema eindeutigen Namensgebung hinderlich. Bei der Erstellung z. B. der Indizes auf der Interimstabelle müssen neue Namen vergeben werden, weil sie mit den Namen der bestehenden Indizes der zu reorganisierenden Tabelle während der Durchführung der Reorganisation koexistieren.

DBMS_REDEFINITION.CAN_REDEF_TABLE ( ‘FIBU‘ , ‘BESTELLUNG‘ );

create table FIBU.BESTELLUNG_2(
  bestellung_nr	NUMBER(10),
  kunden_nr		NUMBER(10),
  artikel_nr	NUMBER(5),
  menge			NUMBER,
  lieferdatum	DATE,
  bemerkung		VARCHAR2(200)
  primary key(bestellung_nr))
  partition by range (bestellung_nr)
  (partition b1 values less than (1000000000),
   partition b2 values less than (2000000000),
   partition b3 values less than (3000000000)) disable primary key;

DBMS_REDEFINITION.START_REDEF_TABLE(
'FIBU','BESTELLUNG','BESTELLUNG_2',
'b_nr bestellung_nr ,k_id kunden_nr');

DBMS_REDFINITION.SYNC_INTERIM_TABLE
('FIBU', 'BESTELLUNG', 'BESTELLUNG_2');

DBMS_REDEFINITION.FINISH_REDEF_TABLE
('FIBU', 'BESTELLUNG', 'BESTELLUNG_2');

Der beschriebene Ablauf hat jedoch gezeigt, wie im laufenden Betrieb eine Tabelle reorganisiert wurde, während die Datenbank und speziell die betroffene Tabelle ständig zur Verfügung standen.

Dr. Konstantin Trachos (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen