Montag, 30. Mai 2011

Aus Oracle nach Google Earth mit Hilfe von KML

Das SDO_UTIL Package (Utility) bietet seit der Version 11g der Oracle Datenbank neue Möglichkeiten für einen direkten Umgang mit der Keyhole Markup Language (KML). 

So können beispielsweise spatiale Geometrien mit Hilfe der Funktion sdo_util.to_kmlgeometry in KML umgewandelt werden. Umgekehrt können mit Hilfe der Funktion sdo_util.from_kmlgeometry KML-Geometrien in spatiale Geometrien umgewandelt werden. 

In diesem Artikel erfahren Sie, wie die Funktion  sdo_util.to_kmlgeometry angewendet wird und wie Sie das Ergebnis zu einem vollständigen KML-Dokument, welches anschließend in Google Earth geladen wird, umwandeln können.  

Schauen wir uns einen einfachen Anwendungsfall an:
SELECT sdo_util.to_kmlgeometry(geometry) KML
FROM  M_ADMIN_AREA2
WHERE
feature_name = 'BERLIN';
Als Ergebnis dieser Abfrage erhalten wir eine KML-Geometrie für das Bundesland Berlin:

KML
---------------------------------------------------------------------------
<Polygon><extrude>0</extrude><tessellate>0</tessellate><altitudeMode>relativeToGround</altitudeMode><outerBoundaryIs><LinearRing><coordinates>
13.56177,52.5804 13.54188,52.58915 13.53483,52.59068 13.50847,52.59241 13.49723,52.60583 13.49827,52.60961 13.50573,52.62563 13.51852,52.63162 13.52244,52.64464 13.5124,52.64478 13.49034,52.65466 13.48478,52.65872 
...
...
13.65677,52.52511 13.65713,52.52987 13.62592,52.53013 13.62523,52.53815 13.63451,52.53879 13.63662,52.54234 13.58706,52.54958 13.58239,52.56993 13.56894,52.57295 13.56177,52.5804
</coordinates></LinearRing></outerBoundaryIs></Polygon>
---------------------------------------------------------------------------
Wenn Sie dieses Ergebnis in einer KML-Datei abspeichern und diese Datei in Google Earth öffnen, dann wird die oben abgefragte Geometrie zunächst nicht angezeigt. Zu einem vollständigen KML-Dokument fehlen neben dem XML-Header noch einige Angaben, die wir mit Hilfe der XML DB, einem Feature welches in jeder Oracle Datenbank enthalten ist, ergänzen werden.

Überprüfen Sie zuerst, ob XML DB bei der Datenbank-Installation mit installiert wurde. Führen Sie dazu im SQL*PLUS die folgende Abfrage aus:
select comp_name, status from dba_registry where comp_name='Oracle XML Database';
Falls diese Funktionalität in Ihrer Datenbank nicht installiert sein sollte, dann können Sie das XML DB Repository mit Hilfe des folgenden Scripts nachinstallieren
 $ORACLE_HOME/rdbms/admin/catqm.sql
Kommen wir zu unserer Ausgangsabfrage zurück und ergänzen diese um die fehlenden Angaben:
SELECT
  xmlelement("kml",
   xmlattributes('http://www.opengis.net/kml/2.2' as "xmlns"),
   xmlelement("Document",
    xmlelement("Placemark",
     xmlelement("name", 'Berlin'),
     xmlelement("Description", 'Flaeche des Bundeslandes Berlin'),
     xmltype(sdo_util.to_kmlgeometry(geometry))
    )
   )
  )
FROM  M_ADMIN_AREA2 WHERE
feature_name = 'BERLIN';
 Das Ergebnis bildet ein vollständiges KML-Dokument:
<kml xmlns="http://www.opengis.net/kml/2.2">
<Document>
<Placemark>
<name>Berlin</name>
<Description>Flaeche des Bundeslandes Berlin</Description>
<Polygon>
<extrude>0</extrude>
<tessellate>0</tessellate>
<altitudeMode>relativeToGround</altitudeMode>
<outerBoundaryIs>
<LinearRing>
<coordinates>13.56177,52.5804 13.54188,52.58915 13.53483,52.59068 13.50847,52.59241 13.49723,52.60583 13.49827,52.60961 13.50573,52.62563 13.51852,52.63162 13.52244,52.64464 13.5124,52.64478 13.49034,52.65466 ...
...
...
13.62592,52.53013 13.62523,52.53815 13.63451,52.53879 13.63662,52.54234 13.58706,52.54958 13.58239,52.56993 13.56894,52.57295 13.56177,52.5804
</coordinates>
</LinearRing>
</outerBoundaryIs>
</Polygon>
</Placemark>
</Document>
</kml>
Speichern Sie das Dokument ab und öffnen Sie es in Google Earth:

Spatiale Geometrie in Google Earth
Mit Hilfe der XML-Funktionen können Sie das KML-Dokument erweitern und weitere Attribute hinzufügen. Probieren Sie diese Abfrage aus:

SELECT
  xmlelement("kml",
   xmlattributes('http://www.opengis.net/kml/2.2' as "xmlns"),
   xmlelement("Document",
    xmlelement("name", 'Berlin.kml'),
    xmlelement("StyleMap", XMLATTRIBUTES('mp' as "id"),
     xmlelement("Pair",
       xmlelement("key",'normal'),
       xmlelement("styleUrl",'#mp_border')
     )
    ),
    xmlelement("Style", XMLATTRIBUTES('mp_border' as "id"),
     xmlelement("LineStyle",
       xmlelement("color",'ffff0000'),
       xmlelement("width",'10')
     )
    ),
    xmlelement("Placemark",
     xmlelement("name", 'Berlin'),
     xmlelement("styleUrl", '#mp'),
     xmlelement("Description", 'Flaeche des Bundeslandes Berlin'),
     xmltype(sdo_util.to_kmlgeometry(geometry))
    )
   )
  )
FROM  M_ADMIN_AREA2 WHERE feature_name = 'BERLIN';
Als Ergebnis erhalten Sie einen blauen Rand um die angezeigte Geometrie:

Spatiale Geometrie mit blauer Umrandung in Google Earth

Donnerstag, 26. Mai 2011

Toleranz und Performanz bei räumlichen Abfragen

In diesem Blogeintrag soll es um die Frage gehen, ob unterschiedliche Werte für den Toleranzparameter Einfluss auf die Performanz räumlicher Abfragen haben.
Die Datenbank arbeitet mit Toleranzen sowohl bei der Definition der SDO-Metadaten als auch bei räumlichen Abfragen. Die Toleranz steht dabei für den Abstand, den 2 (Stütz-)Punkte maximal haben dürfen, um sie als identisch anzusehen. Die Toleranz ist somit ein Mass für die Genauigkeit räumlicher Daten.

Testsituation

Um die anfangs aufgeworfene Frage zu beantworten, wurden zwei Testreihen aufgesetzt, bei denen verschiedene räumliche Funktionen mit skalierenden Toleranzen zur Anwendung kommen. Zwei Testreihen deshalb, um die Auswirkungen für einen relativ kleinen (~8.200 Sätze) und einen größeren Datenbestand (~830.000 Sätze) zu untersuchen.
Die Testdaten, ausschliesslich Polygone mit den 5-stelligen Postleitzahlgeometrien von Deutschland, wurden vom Oracle-Partner GfK GeoMarketing bereitgestellt. Das verwendete Koordinatensystem ist 8307, die Metadaten sind mit einer Toleranz von 0,05 (5 cm) registriert.
An räumlichen Funktionen wurden verwendet:
  • SDO_GEOM.RELATE
  • SDO_GEOM.SDO_ALPHA_SHAPE
  • SDO_GEOM.SDO_AREA
  • SDO_GEOM.SDO_BUFFER
  • SDO_GEOM.SDO_CENTROID
  • SDO_GEOM.SDO_CONCAVEHULL
  • SDO_GEOM.SDO_CONVEXHULL
  • SDO_GEOM.SDO_CONCAVEHULL
  • SDO_GEOM.SDO_DIFFERENCE
  • SDO_GEOM.SDO_DISTANCE
  • SDO_GEOM.SDO_INTERSECTION
  • SDO_GEOM.SDO_TRIANGULATE
  • SDO_GEOM.SDO_UION
  • SDO_GEOM.SIMPLIFY_GEOMETRY
Die Toleranz wurde angefangen mit dem Wert 0.1 (10 cm) pro Iteration verdoppelt bis zum Maximalwert von ~205 (m).
Für die Testsituation wurden nach dem Anlegen der Testtabellen aktuelle Statistiken berechnet.
begin 
  DBMS_STATS.GATHER_TABLE_STATS (
    ownname => '"GFK"',
    tabname => '"TEST_TOL_IMPACT"',
    estimate_percent => 100
  );
end;
Außerdem wurden bei jeder Iteration sowohl Shared Pool als auch Buffer Cache geleert.
alter system flush buffer_cache;
alter system flush shared_pool;
-- Hierfür benötigt der Nutzer alter system Recht 
Dieses Vorgehen ist ausdrücklich nicht für produktive Umgebungen zu empfehlen, dient aber hier der Vergleichbarkeit der Ausführungszeiten.
Diese wurden gemessen, indem für jede räumliche Abfrage vorher als auch hinterher die Total Time sowie CPU Time mittels zweier PL/SQL Funktionen gemessen wurde.
-- Gesamtzeit
create or replace function measure_total_time 
return 
  pls_integer
is
begin
  return dbms_utility.get_time;
end measure_total_time;
/
-- CPU Zeit
create or replace function measure_cpu_time 
return 
  pls_integer
is
begin
  return dbms_utility.get_cpu_time;
end measure_cpu_time;
/
-- Für die Ausführung benötigt der Nutzer das Recht EXECUTE auf dem Package dbms_utility
Die Differenz der vorher und nachher gemessenen Werte jeweils geteilt durch 100 ergibt die Ausführungs- bzw. CPU-Zeit in Sekunden.
Alle Messwerte wurden in 2 Ergebnistabellen festgehalten, mit APEX-Bordmitteln ausgewertet und grafisch als 2D Line Charts mit je einer Serie pro räumlicher Funktion aufbereitet. Die Ergebnisse sind in den Abbildungen am Ende dieses Blogeintrags zu sehen.

Welche Erkenntnisse liefern die Messwerte?

  • Die Annahme, dass die Ausführungszeiten mit geringer werdenden Toleranzwerten (also höherer Genauigkeit) korreliert, hat sich bei keiner der räumlichen Funktionen bestät.
  • Die gemessenen Zeiten für Testreihe 2 (~830.000 Sätze) sind vergleichbar mit denen von Testreihe 1 (~8.200 ätze).
  • Mit gemessenen CPU-Zeiten bis maximal 0,3 sec und durchschnittlichen Gesamtzeiten von 1,3 (Testreihe 1) und 1,5 (Testreihe 2) waren die Abfragen trotz flush shared_pool und flush buffer_cache recht performant.
    Als Testsystem diente ein 64bit Laptop mit Intel i5 Prozessor und 4 GB als maximaler SGA Grösse.
An dieser Stelle möchte ich noch mal darauf hinweisen, dass im Gegensatz zu den Ausführungszeiten die jeweiligen Ergebnismengen nicht im Fokus der Tests standen.

Fazit

Räumliche Abfragen können jeweils mit einer im Hinblick
  • auf die Genauigkeit des Datenbestandes und
  • die erwartete Ergebnismenge
passenden Toleranz ausgeführt werden, ohne dass dies signifikante Auswirkungen auf die Performanz hat.

Abbildungen

Testreihe 1 - Total Time

Testreihe 1 - CPU Time

Testreihe 2 - Total Time

Testreihe 2 - CPU Time

Donnerstag, 5. Mai 2011

Große Geodatenmengen: In Nullkommanix mit Transportable Tablespaces

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.