Gerade im Geodaten-Bereich ist das Übertragen größerer Datenmengen von einer Datenbank
zur anderen nicht selten. Die Standardlösung ist meist Export und Import - ab Oracle10g
gerne auch mit der Data Pump. Wenn man die dazu benötigte Zeit betrachtet, schlägt neben
der Zeit, die das reine Bewegen der Daten benötigt, auch die Zeit zum Indexaufbau
zu Buche; denn ein Export/Import ist im Grunde genommen nichts weiter als das automatisierte
Neu-Erstellen der Tabellen, dann finden SQL-INSERT-Operationen zum Einfügen der neuen Daten statt
und schließlich werden die Indizies neu gebaut. Und wenn die Datenmengen größer
sind, muss man für den letzten Punkt schon etwas Zeit einplanen.
NAVTEQ stellt seine Daten für Oracle Spatial (Kartendarstellung, Geocoding und Routing in der Datenbank)
daher als Transportable Tablespace bereit. 150G Daten für die EU lassen sich so in 15 Minuten
einspielen - obwohl die Neu-Erstellung aller Spatial-Indizes alleine sicherlich mehrere Stunden
brauchen würde. Und diese Möglichkeit ist nicht NAVTEQ alleine vorbehalten. Transportable Tablespaces
können mit jeder Datenbank bereitgestellt werden (Export), möchte man sie importieren, so wird
eine Enterprise Edition benötigt.
Verwendet man Transportable Tablespaces, so exportiert das Export-Werkzeug (expdp) nur noch
die Metadaten - es wird keine einzige Tabellenzeile bewegt. Zum Übertragen der Daten wird dann
schließlich die Orginal-Datendatei vom Quell- auf das Zielsystem kopiert. Beim Importieren
der Metadaten wird die Datei schließlich in die Datenbank eingehängt und alle Daten sind sofort
da - auch alle Spatial-Indizes stehen sofort bereit. Und im folgenden ist anhand eines
Beispiels beschrieben, wie man mit Transportable Tablespaces arbeitet.
Export: Vorbereitungen
Zunächst muss überpüft werden, ob das Tablespace self-contained ist, das heißt, dass keine
Abhängigkeiten zu Objekten in anderen Tablespaces vorhanden sind. Diese Prüfung muss man nicht selbst
machen, die Prozedur DBMS_TTS.TRANSPORT_SET_CHECK übernimmt das. Der folgende Aufruf prüft also nach,
ob der Tablespace GEOWS problemlos zu einer anderen Datenbank transportiert werden kann.
begin
DBMS_TTS.TRANSPORT_SET_CHECK('GEOWS', TRUE, TRUE);
end;
Die Ergebnisse der Prüfung finden sich dann in der Dictionary View TRANSPORT_SET_VIOLATIONS.
SQL> select * from transport_set_violations;
no rows selected.
Wenn man auf einer 11.2-Datenbank arbeitet, kann der nächste Schritt übersprungen werden. Alle anderen
müssen nun die Spatial-Indizes "vorbereiten"; es müssen Metainformationen aufgezeichnet werden, damit
die Indizes auf der Zieldatenbank wiederhergestellt werden können. Das geht mit der Prozedur
SDO_UTIL.PREPARE_FOR_TTS wie folgt (man muss als
Eigentümer der Daten eingeloggt sein).
begin
sdo_util.prepare_for_tts;
end;
Wie gesagt: Ab Datenbankversion 11.2 ist das nicht mehr nötig. Die dann folgenden Schritte
müssen wiederum bei allen Datenbankversionen durchgeführt werden: Da die Datendatei mit Betriebssystem-Mitteln kopiert werden wird, darf die Datenbank sie nicht mehr verändern. Jetzt ist also der richtige Zeitpunkt, das
Tablespace read only zu setzen. Also als DBA:
alter tablespace geows read only;
Export
Nun erfolgt das eigentliche Exportieren mit der Data Pump. Es wird ein Directory-Objekt benötigt, in welches
die Data Pump das Dumpfile (welches nur noch Metadaten enthält) schreiben soll. Das wird als DBA angelegt.
create directory expdir as '/path/to/folder/for/dumpfile';
Und dann kommt das eigentliche Exportieren ... auch das wird als DBA durchgeführt und nicht als
Schema-Eigentümer.
$ expdp userid=system/{password}
dumpfile=geows.dmp
directory=expdir
transport_tablespaces=geows
logfile=exp_geows.log
Export: Release 11.2.0.2.0 - Production on Thu May 5 13:44:03 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining
and Real Application Testing options
Starting "SYSTEM"."SYS_EXPORT_TRANSPORTABLE_01": userid=system/******** dumpfile=geows.dmp directory=homedir transport_tablespaces=geows logfile=exp_geows.log
Processing object type TRANSPORTABLE_EXPORT/PLUGTS_BLK
Processing object type TRANSPORTABLE_EXPORT/TABLE
Processing object type TRANSPORTABLE_EXPORT/GRANT/OWNER_GRANT/OBJECT_GRANT
Processing object type TRANSPORTABLE_EXPORT/TABLE_STATISTICS
Processing object type TRANSPORTABLE_EXPORT/DOMAIN_INDEX/TABLE
Processing object type TRANSPORTABLE_EXPORT/DOMAIN_INDEX/INDEX
Processing object type TRANSPORTABLE_EXPORT/POST_INSTANCE/PLUGTS_BLK
Master table "SYSTEM"."SYS_EXPORT_TRANSPORTABLE_01" successfully loaded/unloaded
******************************************************************************
Dump file set for SYSTEM.SYS_EXPORT_TRANSPORTABLE_01 is:
/path/to/folder/for/dumpfile/geows.dmp
******************************************************************************
Datafiles required for transportable tablespace GEOWS:
/opt/oracle/oradata/orcl/geows01.dbf
Job "SYSTEM"."SYS_EXPORT_TRANSPORTABLE_01" successfully completed at 13:45:30
Die letzten vier Zeilen der Ausgabe beschreiben, wo die nötigen Dateien zu finden sind;
diese können jetzt mit Betriebssystemmitteln kopiert, als Archiv gepackt und auf das
Zielsystem übertragen, auf CD gebrannt oder zum Download bereitgestellt werden.
Import: Vorbereitungen
Auf dem Zielsystem muss zunächst das Datenbankschema angelegt werden. Es sollte (wie immer)
alle Privilegien haben, die auch auf dem Quellsystem vorhanden waren. Als nächstes muss ein
Blick auf die Betriebssystem-Plattformen von Quell- und Zielsystem geworfen werden.
Denn wie Oracle die Bytes in seinen Datendateien anordnet, hängt von der Plattform ab.
Big Endian-Plattformen arbeiten anders als Little Endian-Plattformen. Aber
die Datenbank weiß Bescheid.
SQL> SELECT * FROM V$TRANSPORTABLE_PLATFORM ORDER BY PLATFORM_NAME
PLATFORM_ID PLATFORM_NAME ENDIAN_FORMAT
----------- ------------------------------------ --------------
6 AIX-Based Systems (64-bit) Big
16 Apple Mac OS Big
21 Apple Mac OS (x86-64) Little
19 HP IA Open VMS Little
4 HP-UX IA (64-bit) Big
18 IBM Power Based Linux Big
9 IBM zSeries Based Linux Big
10 Linux IA (32-bit) Little
11 Linux IA (64-bit) Little
13 Linux x86 64-bit Little
7 Microsoft Windows IA (32-bit) Little
12 Microsoft Windows x86 64-bit Little
17 Solaris Operating System (x86) Little
: : :
Die Datendateien können also von einer Linux- problemlos auf eine Windows-Plattform
übertragen werden, da beide Plattformen Little-Endian-Plattformen sind. Beim
Übertragen von Windows auf bspw. HP-UX IA 64bit wird es dagegen Probleme geben - die Datenbank
dort könnte die Dateien gar nicht lesen. Aber das ist kein Problem - denn die Dateien können
konvertiert werden. Diese Konvertierung wird mit dem RMAN-Werkzeug und dem Kommando
CONVERT entwieder auf dem Quell-
oder auf dem Zielsystem durchgeführt - je nachdem, ob man die Zielplattform beim Exportieren
schon kennt oder nicht.
Konvertiert man auf dem Quellsystem, so verwendet man das RMAN-Kommando CONVERT TABLESPACE.
$ RMAN TARGET /
Recovery Manager: Release 11.2.0.2.0
Copyright (c) 1982, 2009, Oracle. All rights reserved.
connected to target database: ORCL (DBID=1277326448)
RMAN> convert tablespace geows
to_platform = "HP-UX (64-bit)"
format='/home/oracle/hpux%U';
Starting conversion at source at 05-MAY-11
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile conversion
input datafile file number=00008 name=/opt/oracle/oradata/orcl/geows01.dbf
converted datafile=/home/oracle/hpuxdata_D-ORCL_I-1277326448_TS-GEOWS_FNO-8_01mbiqgn
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:25
Finished conversion at source at 05-MAY-11
Konvertiert man auf dem Zielsystem, so nutzt man das Kommando CONVERT DATAFILE.
$ RMAN TARGET /
Recovery Manager: Release 11.2.0.2.0
Copyright (c) 1982, 2009, Oracle. All rights reserved.
connected to target database: ORCL (DBID=1277326448)
RMAN> convert datafile '/home/oracle/geows01_hpux.dbf'
TO PLATFORM="Linux IA (32-bit)"
FROM PLATFORM="HP-UX (64-bit)"
DB_FILE_NAME_CONVERT=
'/geows01_hpux'
'/geows01_linux';
Starting conversion at target at 05-MAY-11
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=61 device type=DISK
channel ORA_DISK_1: starting datafile conversion
input file name=/home/oracle/geows01_hpux.dbf
converted datafile=/home/oracle/geows01_linux.dbf
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:16
Finished conversion at target at 05-MAY-11
Importieren
Als nächstes wird die (ggfs. konvertierte) Datendatei dorthin kopiert, wo sie später liegen soll;
auf den meisten Systemen dürfte das dort sein, wo auch schon die anderen Datenbankdateien liegen.
Der nächste Schritt ist nun das Einspielen der Metadaten und das Einhängen der Datendatei in
die Datenbank mit dem Data Pump-Werkzeug impdp.
$ impdp userid=system/oracle
dumpfile=geows.dmp
directory=homedir
transport_datafiles=/location/where/datafile/has/been/copied/to/geows01_linux.dbf
logfile=import.log
Import: Release 11.2.0.2.0 - Production on Thu May 5 14:26:10 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Produc tion
With the Partitioning, Oracle Label Security, OLAP, Data Mining
and Real Application Testing options
Master table "SYSTEM"."SYS_IMPORT_TRANSPORTABLE_01" successfully loaded/unloaded
Starting "SYSTEM"."SYS_IMPORT_TRANSPORTABLE_01": userid=system/******** dumpfil e=geows.dmp directory=homedir transport_datafiles=/opt/oracle/oradata/orcl/geows 01.dbf logfile=import.log
Processing object type TRANSPORTABLE_EXPORT/PLUGTS_BLK
Processing object type TRANSPORTABLE_EXPORT/TABLE
Processing object type TRANSPORTABLE_EXPORT/GRANT/OWNER_GRANT/OBJECT_GRANT
Processing object type TRANSPORTABLE_EXPORT/TABLE_STATISTICS
Processing object type TRANSPORTABLE_EXPORT/DOMAIN_INDEX/TABLE
Processing object type TRANSPORTABLE_EXPORT/DOMAIN_INDEX/INDEX
Processing object type TRANSPORTABLE_EXPORT/POST_INSTANCE/PLUGTS_BLK
Job "SYSTEM"."SYS_IMPORT_TRANSPORTABLE_01" successfully completed at 14:26:31
Dieser Vorgang dauert unabhängig von der Größe der übertragenen Tablespaces nur wenige Sekunden. Auch
extrem große Datenmengen lassen sich so sehr einfach einspielen. Wenn impdp fertig ist, sind alle
Daten im Schema vorhanden und man kann schon (fast) loslegen.
Spatial-Indizes initialisieren
Weiter oben wurde bereits geschrieben, dass die Spatial-Indizes mit SDO_UTIL.PREPARE_FOR_TTS
"vorbereitet" werden müssen, wenn die Datenbankversion 11.1 oder niedriger ist. Ab Datenbankversion
11.2 ist der Schritt nicht nötig. Werden auf diese Weise "vorbereitete" Spatial-Indizes in das Zielsystem
eingespielt, so müssen diese mit SDO_UTIL.INITIALIZE_INDEXES_FOR_TTS initialisiert werden. Die
Dokumentation beschreibt, wie das Kommando ausgeführt werden muss. Die Initialisierung muss auch
durchgeführt werden, wenn das Quellsystem zwar eine 11.2-Datenbank ist, die Datendateien aber wegen
unterschiedlicher Plattformen konvertiert werden mussten. Der Aufruf ist in beiden Fällen recht
einfach:
begin
sdo_util.initialize_indexes_for_tts;
end;
Wurden die Daten aus einer Datenbankversion "vor" 11.2 exportiert, so muss für jeden Spatial-Index
noch folgendes Kommando ablaufen ...
ALTER INDEX {spatial-index-name} PARAMETERS ('CLEAR_TTS=TRUE');
Das kann recht einfach per Skript erledigt werden.
declare
v_ddl varchar2(200);
begin
for i in (
select sdo.sdo_index_name
from user_sdo_index_metadata sdo, user_tables ut
where ut.table_name = sdo.sdo_index_table
and ut.tablespace_name = 'GEOWS'
) loop
v_ddl := 'alter index ' || i.sdo_index_name || ' parameters (''CLEAR_TTS=TRUE'')';
execute immediate v_ddl;
dbms_output.put_line(v_ddl || ' executed.');
end loop;
end;
Und dann ist der Vorgang abgeschlossen. Im Vergleich zu einem "normalen" Export und Import ist
das sicherlich etwas aufwändiger und es sind mehr Dinge, auf die man achten muss ... aber die
Vorteile kommen, sobald die Datenmengen etwas größer werden. Als ich vor einigen Wochen einen
größeren Datenbestand (gezippt 400MB) einspielen musste, war der "klassische" Import ca.
2 Stunden beschäftigt. Mit Transportable Tablespaces wäre es eine Sache von drei Minuten gewesen. Und
wenn man nun daran denkt, dass manche Datenbestände regelmäßig aktualisiert werden müssen ...
... ach ja: genau hier kann man auch von Anbietern wie NAVTEQ lernen. Denn bei regelmäßigen
Aktualisierungen kommt es ja unter Umständen zur Situation, dass man das neue Tablespace gerne
einspielen, die alte Version aber vielleicht gerne behalten möchte. In solchen Fällen ist es also
durchaus sinnvoll, die "Versionsnummer" in den Namen des Tablespace und des Datenbankschemas
aufzunehmen. NAVTEQ macht es so: Das ODF-Dataset Q3/2010 wird in den Tablespace ODF_EU_Q310 und
das Datenbankschema ODF_EU_Q310 eingespielt. Für andere Schemas kann man die Daten ja dann
mit GRANT- und CREATE SYNONYM-Anweisungen sichtbar machen.
