Transportable Tablespaces: Grundlagen und Einsatz am Beispiel
von Ulrike Schwinn, ORACLE Deutschland GmbH

Transportable Tablespaces, ein Feature der Enterprise Edition, ist schon seit Oracle8i ein sehr gutes Mittel, um Daten schnell und effizient zwischen Datenbanken zu transportieren. Die Idee dabei ist, "nur" die Metadaten eines Tablespaces zu exportieren und eine Kopie der Datendateien zur Verfügung zu stellen. Nachdem die Datendateien auf dem Zielsystem zur Verfügung stehen, erfolgt als abschliessende Operation nur noch ein Import der zugehörigen Metadaten. Aus diesem Grund kann diese Technik wesentlich schneller Daten bewegen als ein traditioneller Datenbank-Export bzw.Import.

Das Vorhandensein einer Enterprise Edition ist dabei zum Erzeugen des transportierbaren Sets notwendig; das Plugin des Sets kann in jede Edition der Datenbank erfolgen. Unterschiedliche Blockgrößen bzw. unterschiedliche Plattformen der Datenbanken (z.B. von Windows nach Solaris) stellen seit Oracle 9i bzw. 10g kein Hindernis mehr dar. Ausgehend von einem älteren Datenbankrelease (ab Oracle 8i) ist der Transport auch in ein neueres Release - beispielsweise in Oracle 9i, 10g oder 11g möglich. Der Einsatz ist vielfältig und wird von Kunden erfolgreich genutzt. Auch im Migrationsumfeld hat sich der Einsatz von Transportable Tablespaces bewährt. Liegt ein grosses Datenvolumen vor und ist die Transportzeit begrenzt, sind die Vorteile, die die Transportable Tablespace Technologie bietet, im Vergleich zu anderen Techniken nicht zu übertreffen.

Folgende Beispiele zeigen sinnvolle Einsatz-Szenarien.

  • Transport von Partitionen
  • Archivierung von Daten
  • Plattform-Migrationen
  • Datenbank-Migrationen
Im folgenden Tipp werden wir einen Transport ausführlich erläutern. Das erste Szenario - der Transport von Partitionen - dient dabei als Beispiel.

Bevor man diese Technik als Transportmittel einsetzt, sollten die Einschränkungen beachtet werden. Folgende Liste gibt einen Überblick:
  • Verwendung des gleichen Zeichensatzen (Characterset und National Characterset)
  • Verwendung von "self-contained" Objekten (D.h. es dürfen keine Abhängigkeiten ausserhalb des transportierenden Sets existieren)
  • Kein Transport von Objekten im SYSTEM Tablespace
  • Einschränkungen bei der Nutzung von verschlüsselten Tablespaces und XMLTYPEs
  • Keine Namensgleichheit der Tablespaces im Ziel- und Quellsystem
Eine vollständige Liste findet sich im Oracle Database Administrator's Guide 11g Release 2 (11.2).

Überprüfung der Voraussetzungen
Bevor wir an einem Beispiel den Transport durchführen, wird überprüft, ob der gleiche Zeichensatz verwendet wird. Folgende Abfrage überprüft den Zeichensatz und sollte auf beiden Systemen durchgeführt werden. 
-- Zeichensatz abfragen
SQL> SELECT * FROM nls_database_parameters WHERE parameter LIKE '%CHARACTERSET%';
PARAMETER                      VALUE
------------------------------ ----------------------------------------
NLS_CHARACTERSET               WE8MSWIN1252
NLS_NCHAR_CHARACTERSET         AL16UTF16
Nehmen wir als Beispielumgebung die partitionierte Tabelle COSTS, die um eine Partition COSTS_Q4_2006 erweitert werden soll. Die Daten liegen in der Datenbank A in einer nicht partitionierten Tabelle COST_NEU, die die gleiche Struktur wie die Tabelle COSTS aufweist. Dabei liegen die Tabelle und die Indizes in einem separaten Tablespace COST_PART, der "self-contained" ist. In folgendem Listing werden die notwendigen Voraussetzungen für das Beispiel geschaffen. 
-- Datenbank A
-- Leere Tabelle im Tablespace COST_PART erzeugen
SQL> CREATE TABLE cost_neu TABLESPACE cost_part AS SELECT * FROM costs WHERE 1=0;
-- Tabelle mit Daten befüllen
SQL> INSERT INTO cost_neu 
     SELECT prod_id, time_id+365*5, promo_id, channel_id, unit_cost, unit_price 
     FROM costs PARTITION (COSTS_Q4_2001) WHERE rownum<100;
-- Zugehörige Indizes erzeugen
SQL> CREATE BITMAP INDEX costs_part_time ON cost_neu(time_id) TABLESPACE cost_part;
SQL> CREATE BITMAP INDEX costs_part_prod ON cost_neu(prod_id) TABLESPACE cost_part;
Im nächsten Schritt wird überprüft, ob der Tablespace transportierbar - auch self-contained - ist. Dies wird mit dem Package DBMS_TTS durchgeführt. Setzt man das zweite Argument auf den Wert TRUE, werden auch die zugehörigen Constraints überprüft. Folgendes Beispiel zeigt die Verwendung. 
SQL> connect / as sysdba

SQL> EXECUTE DBMS_TTS.TRANSPORT_SET_CHECK(TS_LIST => 'COST_PART', INCL_CONSTRAINTS => TRUE);
SQL> SELECT * FROM TRANSPORT_SET_VIOLATIONS;
no rows selected

Der Transport
Nun kann der Transport beginnen! Dazu wird zuerst der Tablespace COST_PART in der Datenbank A auf READ ONLY gesetzt. Danach werden die Metadaten mit dem Werkzeug Data Pump exportiert. 
SQL> ALTER TABLESPACE cost_part read only;

$ expdp system dumpfile=cost_neu.dmp directory=transdir 
        transport_tablespaces=cost_part logfile=tts_export.log
Hinweis: Wird die Transportable Tablespaces Technologie in älteren Versionen ab Version 8i genutzt, wird das EXPORT/IMPORT Werkzeug statt Data Pump verwendet. Mehr dazu findet sich im Oracle Database Utilities 11g Release 2 (11.2)

Da es sich beim Data Pump Export "nur" um Metadaten-Informationen handelt, ist diese Operation schnell durchgeführt. Nun werden die Dump-Datei cost_neu.dmp und die Datendateien cost_part.dbf des Tablespace COST_PART auf den Server der Datenbank B kopiert. Diese Operation ist in der Regel die Zeitaufwändigste. Danach kann der Tablespace COST_PART wieder auf READ WRITE gesetzt werden. 
SQL> ALTER TABLESPACE cost_part READ WRITE;
Bevor die Metadaten importiert werden, sehen wir uns die Zieltabelle etwas genauer an. Die Tabellenpartitionen liegen "direct load" komprimiert vor, und die Bitmap Indizes sind im Status "USABLE". 
SQL> SELECT table_name, partition_name, compression, compress_for 
     FROM dba_tab_partitions WHERE table_name LIKE 'COST%'

TABLE_NAME PARTITION_NAME                 COMPRESS COMPRESS_FOR
---------- ------------------------------ -------- ------------
COSTS      COSTS_1995                     ENABLED  BASIC
COSTS      COSTS_1996                     ENABLED  BASIC
COSTS      COSTS_H1_1997                  ENABLED  BASIC
COSTS      COSTS_H2_1997                  ENABLED  BASIC
COSTS      COSTS_Q1_1998                  ENABLED  BASIC
COSTS      COSTS_Q2_1998                  ENABLED  BASIC
COSTS      COSTS_Q3_1998                  ENABLED  BASIC
COSTS      COSTS_Q4_1998                  ENABLED  BASIC
COSTS      COSTS_Q1_1999                  ENABLED  BASIC
COSTS      COSTS_Q2_1999                  ENABLED  BASIC
COSTS      COSTS_Q3_1999                  ENABLED  BASIC
...
SQL> SELECT index_name, table_name FROM user_indexes WHERE table_name='COSTS';

INDEX_NAME                     TABLE_NAME
------------------------------ ------------------------------
COSTS_PROD_BIX                 COSTS
COSTS_TIME_BIX                 COSTS

SQL> SELECT partition_name, status FROM user_ind_partitions 
     WHERE index_name IN ('COSTS_PROD_BIX', 'COSTS_TIME_BIX');

PARTITION_NAME                 STATUS
------------------------------ --------
COSTS_1995                     USABLE
COSTS_1996                     USABLE
COSTS_H1_1997                  USABLE
COSTS_H2_1997                  USABLE
COSTS_Q1_1998                  USABLE
COSTS_Q1_1999                  USABLE
COSTS_Q1_2000                  USABLE
...
Nun erfolgt der Import der Metadaten auf den Server mit Datenbank B. 
$ impdp system dumpfile=cost_neu.dmp directory=data_pump_dir 
        transport_datafiles=/space/oradata/11g/cost_part.dbf logfile=tts_import.log
Nach dem Import liegen die Tabelle COST_NEU und die zugehörigen Indizes im transportierten Tablespace COST_PART in der Datenbank B vor. Die folgende Abfrage zeigt die vorhandenen Segmente und den Status der Indizes. 
SQL> SELECT tablespace_name, status FROM dba_tablespaces;

TABLESPACE_NAME                STATUS
------------------------------ ---------
SYSTEM                         ONLINE
SYSAUX                         ONLINE
UNDOTBS1                       ONLINE
TEMP                           ONLINE
EXAMPLE                        ONLINE
USERS                          ONLINE
COST_PART                      READ ONLY

SQL> SELECT index_name, status, tablespace_name FROM dba_indexes 
     WHERE table_name='COST_NEU';

INDEX_NAME                     STATUS   TABLESPACE_NAME
------------------------------ -------- ------------------------------
COSTS_PART_PROD                VALID    COST_PART
COSTS_PART_TIME                VALID    COST_PART

SQL> ALTER TABLESPACE cost_part READ WRITE;
Nun wird die Tabelle COSTS um die leere Partition COST_Q4_2006 erweitert und erhält die Eigenschaft COMPRESS. Das anschliessende EXCHANGE Kommando soll die entsprechenden Daten in die Tabelle COSTS kopieren und die beiden Indizes COSTS_PART_PROD und COSTS_PART_TIME in die Indexpartitionen konvertieren. Die Option WITHOUT VALIDATION beschleunigt die Operation, da keine Validierung der Partitionen vorgenommen wird. 
SQL> ALTER TABLE costs ADD PARTITION costs_q4_2006 
     VALUES LESS THAN (to_date('2006-01-01','YYYY-MM-DD')) COMPRESS;
SQL> ALTER TABLE COSTS EXCHANGE PARTITION costs_q4_2006 
     WITH TABLE cost_neu INCLUDING INDEXES WITHOUT VALIDATION;

ORA-14646: Specified alter table operation involving compression cannot be
performed in the presence of usable bitmap indexes
Die Fehlermeldung beschreibt sehr treffend, wo das Problem liegt und wie es zu beheben ist. Die Tabelle COSTS besitzt komprimierte Partitionen und "USABLE" Bitmap Indizes, wie wir zu Beginn überprüft haben. Das Hinzufügen von Daten zu einer komprimierten Tabelle bspw. mit dem EXCHANGE-Kommando kann nicht durchgeführt werden, da die Indizes den Status "USABLE" haben. Nachdem wir die Indizes der Tabelle COST_NEU und die zugehörigen Indexpartitionen der Tabelle COSTS auf "UNUSABLE" geschaltet haben, ist das EXCHANGE-Kommando erfolgreich. Dies ist notwendig, da bei komprimierten Tabellen potentiell mehr Zeilen in einem Datenblock addressiert werden können. Danach führen wir die entsprechenden REBUILD Kommandos durch. Diese Operationen müssen nach weiteren Einfüge-Operationen NICHT wiederholt werden! 
-- Indizes der Tabelle COST_NEU
SQL> ALTER INDEX costs_part_time UNUSABLE;
SQL> ALTER INDEX costs_part_prod UNUSABLE;
-- zugehörigen Indexpartitionen
SQL> ALTER INDEX costs_prod_bix MODIFY PARTITION costs_q4_2006 UNUSABLE;
SQL> AKTER INDEX costs_time_bix MODIFY PARTITION costs_q4_2006 UNSUABLE;

SQL> ALTER TABLE costs EXCHANGE PARTITION costs_q4_2006 WITH TABLE cost_neu 
     INCLUDING INDEXES WITHOUT VALIDATION;
Table altered.
-- die Indexpartitionen auf usable schalten
SQL> ALTER INDEX costs_prod_bix REBUILD PARTITION costs_q4_2006;
SQL> ALTER INDEX costs_time_bix REBUILD PARTITION costs_q4_2006;
Danach ist die Tabelle COST_NEU leer und kann gelöscht werden.

Mögliche Variante: Nutzung unterschiedlicher Plattformen
Nehmen wir an, dass Datenbank A und Datenbank B auf Plattformen mit unterschiedlicher Endianness (big bzw. little) installiert sind. Dies ist beispielsweise der Fall, wenn Linux und Solaris als Plattformen verwendet werden. Ab Oracle Version 10g können die Datendateien mit Datenbankmitteln konvertiert werden, und somit kann ein Transport zwischen Plattformen mit unterschiedlicher Endianness ermöglicht werden. Diese Konvertierung muss vor dem Import der Metadaten der Datendateien erfolgen. Die genutzte Endianness lässt sich dabei mit folgender Abfrage verifizieren. 
-- Datenbank B
SQL> SELECT d.PLATFORM_NAME, ENDIAN_FORMAT
     FROM V$TRANSPORTABLE_PLATFORM tp, V$DATABASE d
     WHERE tp.PLATFORM_NAME = d.PLATFORM_NAME;

PLATFORM_NAME             ENDIAN_FORMAT
------------------------- --------------
Linux IA (32-bit)         Little

-- Datenbank A
SQL> SELECT d.PLATFORM_NAME, ENDIAN_FORMAT
     FROM V$TRANSPORTABLE_PLATFORM tp, V$DATABASE d
     WHERE tp.PLATFORM_NAME = d.PLATFORM_NAME;

PLATFORM_NAME             ENDIAN_FORMAT
------------------------- --------------
Solaris[tm] OE (64-bit)   Big
Die Konvertierung erfolgt mit dem RMAN Werkzeug und kann entweder auf dem Ziel- oder dem Quellsystem durchgeführt werden. Dabei ist zu beachten, dass bei Angabe der Plattform die richtigen Schlüsselwörter (siehe v$transportable_platform) verwendet werden. Folgendes Beispiel zeigt die Verwendung. 
RMAN> CONVERT DATAFILE '/tmp/cost_part.dbf' TO PLATFORM="Linux IA (32-bit)"
FROM PLATFORM="Solaris[tm] OE (64-bit)" DB_FILE_NAME_CONVERT='/tmp', '/space2/oradata';
Die Datei wurde im vorangegangen Kopiervorgang nach /tmp kopiert. Nach der Konvertierung liegt sie im Datendatei-Verzeichnis /space2/oradata/ der Datenbank B vor.

Mögliche Variante: ASM Instanzen
Das vorangegangenen Beispiel berücksichtigte keine ASM Instancen. Ist ASM im Einsatz, muss zusätzlich berücksichtigt werden, wie die Dateien zwischen den Systemen kopiert werden können. Dabei bieten sich folgende Möglichkeiten an:
  • Nutzung von RMAN Kommandos wie z.B. CONVERT TABLESPACE ...DATAFILE '...' (auf dem Quellsystem) bzw. BACKUP AS COPY DATAFILE '...' FORMAT '+DGROUPA' (auf dem Zielsystem)
  • Verwendung des Package DBMS_FILE_TRANSFER
  • Verwendung des cp Kommandos im Linemode-Werkzeug ASMCMD (ab 11g)
  • Nutzung der FTP bzw HTTP Protokolle der XMLDB für ASM (ab Oracle Version 10.2)
Die ausführliche Beschreibung dieser Techniken würde den Rahmen dieses Beitrags sprengen, daher sei auf die RMAN Dokumentation, zukünftige Ausgaben der DBA Community und Note 394798.1 verwiesen.

Fazit
Die Transportable Tablespace Technologie ist einfach zu verwenden. Zudem bietet sie eine gute Alternative, um Daten schnell zu bewegen, da die meisten Operationen bis auf die Kopie der Datendateien sehr schnell durchgeführt werden können. Dabei stehen die beiden System nahezu uneingeschränkt zur Verfügung bis auf die Zeitspanne, in der die zu transportierenden Tablespaces READ ONLY gesetzt sind. Zusätzlich eignet sich die Transportable Tablespace Technologie sehr gut zur Migration von Plattformen bzw. Datenbankreleases. Die Idee dabei ist, alle Tablespaces ausser den SYSTEM Tablespace zu transportieren - wie im Beispiel gezeigt wurde. Danach werden die fehlenden Data Dictionary Informationen in einem separaten Import ohne zusätzliche Dateninformationen bzw. mit zusätzlichen Skripten hinzugefügt.

Mehr zu diesem Thema lesen Sie in den nächsten Ausgaben ...



Zurück zur Community-Seite