Table of Contents
Ziel
In diesem Blogbeitrag wird die Migration von Daten zwischen zwei Datenbanken mithilfe von Transportable Tablespaces demonstriert. Die Migration umschließt die folgenden Änderungen:
- Architektur: von x86 nach x64
- Betriebssystem: von CentOs 5.5 nach Windows Server 2008 R2
- Oracle: von 10g Release 2 nach 11g Release 2
Was sind Transportable Tablespaces?
Oracle führte die Transportable Tablespaces als Enterprise Edition Feature mit Version 8i ein. Mit diesem Feature war es möglich Daten schnell und effizient zwischen zwei Datenbanksystemen auszutauschen. Die Idee dahinter war, dass die Datenbankdateien auf das neue System kopiert werden und anschließend werden die Data Dictionary Metadaten für das/die Tablespace/s importiert. Diese Technology kann auch für Migrationen ein gutes Mittel darstellen.
Voraussetzungen
Dieser Blogbeitrag setzt zwei vorinstallierte und konfigurierte Systeme voraus. Die Anforderungen an die Konfigurationen wurden unter Ziel aufgeführt.
Die Datenbankdateien liegen in meinen Testumgebungen jeweils in einer ASM Diskgruppe. Die Dateien können aber genauso gut im Dateisystem liegen. Auf mögliche Unterschiede zwischen ASM und Dateisystem gehe ich bei der Durchführung ein.
Für die Überführung eines Tablespaces vom Quell- zum Zielsystem werde ich zunächst ein Tablespace, einen Benutzer und Beispieldaten in der Quelldatenbank anlegen. Dies bildet die Grundlage für die Migration.
[oracle@rac2 ~]$ sqlplus / as sysdba SQL*Plus: Release 10.2.0.4.0 - Production on Thu Jan 6 16:44:53 2011 Copyright (c) 1982, 2007, Oracle. All Rights Reserved. Verbunden mit: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production With the Partitioning, Real Application Clusters, OLAP, Data Mining and Real Application Testing options SQL> create tablespace tts_data datafile size 100m; SQL> create user tts_user identified by tts_user default tablespace tts_data; SQL> grant dba to tts_user;
Hinweis: Der Benutzer muss nicht die DBA Rolle besitzen. Ich habe diese nur zur Vereinfachung dem Benutzer zugewiesen, da ich die Beispieldaten anhand von Daten aus dem Data Dictionary erstelle.
SQL> connect tts_user/tts_user Connect durchgefuhrt. SQL> create table sys_obs as select object_name, object_type from dba_objects where owner='SYS'; SQL> select count(*) from sys_obs; COUNT(*) ---------- 6929
Die Beispieltabelle enthält nun knapp 7000 Zeilen. Dies sollte zur Veranschaulichung ausreichen.
Im folgenden ein paar Informationen über das Betriebssystem und die Datenbankversion der beiden Systeme.
Quelldatenbank
SQL> select * from v$version; BANNER ---------------------------------------------------------------- Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Prod PL/SQL Release 10.2.0.4.0 - Production CORE 10.2.0.4.0 Production TNS for Linux: Version 10.2.0.4.0 - Production NLSRTL Version 10.2.0.4.0 - Production 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
Zieldatenbank
SQL> select * from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production PL/SQL Release 11.2.0.1.0 - Production CORE 11.2.0.1.0 Production TNS for 64-bit Windows: Version 11.2.0.1.0 - Production NLSRTL Version 11.2.0.1.0 - Production 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 ------------------------------ -------------- Microsoft Windows x86 64-bit Little
Überprüfung der beiden Systeme
Bevor ein Tablespace zwischen zwei Systemen ausgetauscht werden kann, muss zunächst überprüft werden, ob der Transport überhaupt möglich.
Character Set
Das Character Set und das National Character Set muss in beiden Datenbanken identisch sein, damit der Transport erfolgreich durchgeführt werden kann.
Quelldatenbank
SQL> select * from nls_database_parameters where parameter like '%SET%'; PARAMETER VALUE ------------------------------ ---------------------------------------- NLS_CHARACTERSET WE8ISO8859P1 NLS_NCHAR_CHARACTERSET AL16UTF16
Zieldatenbank
SQL> select * from nls_database_parameters where parameter like '%SET%'; PARAMETER VALUE ------------------------------ ---------------------------------------- NLS_CHARACTERSET WE8ISO8859P1 NLS_NCHAR_CHARACTERSET AL16UTF16
Wie man sieht sind sowohl das Character Set als auch das National Charater Set identisch.
Transport Zielplattform überprüfen
Die View V$TRANSPORTABLE_PLATFORM listet alle möglichen Zielplattformen für den Transport auf.
SQL> select platform_id, platform_name, endian_format from v$transportable_platform order by endian_format, platform_id PLATFORM_ID PLATFORM_NAME ENDIAN_FORMAT ----------- ---------------------------------------- -------------- 1 Solaris[tm] OE (32-bit) Big 2 Solaris[tm] OE (64-bit) Big 3 HP-UX (64-bit) Big 4 HP-UX IA (64-bit) Big 6 AIX-Based Systems (64-bit) Big 9 IBM zSeries Based Linux Big 16 Apple Mac OS Big 18 IBM Power Based Linux Big 5 HP Tru64 UNIX Little 7 Microsoft Windows IA (32-bit) Little 8 Microsoft Windows IA (64-bit) Little 10 Linux IA (32-bit) Little 11 Linux IA (64-bit) Little 12 Microsoft Windows x86 64-bit Little 13 Linux x86 64-bit Little 15 HP Open VMS Little 17 Solaris Operating System (x86) Little 19 HP IA Open VMS Little 20 Solaris Operating System (x86-64) Little
Wie man sieht ist der Transport von Tablespaces zu der Zielplattform Microsoft Windows x86 64-bit möglich.
XMLType Spalten überprüfen
Der Transport von Tabellen mit XMLType Spalten ist erst mit Oracle 10g Release 2 möglich. Dann muss aber anstat DataPump für den Export und Import der Metadaten EXP bzw. IMP verwendet werden. Die folgende SQL Query wird in der Quelldatenbank ausgeführt.
SQL> select distinct p.tablespace_name from dba_tablespaces p, dba_xml_tables x, dba_users u, all_all_tables t where t.table_name=x.table_name and t.tablespace_name=p.tablespace_name and x.owner=u.username; dba_xml_tables x, dba_users u, all_all_tables t where* FEHLER in Zeile 2: ORA-00942: Tabelle oder View nicht vorhanden
Hinweis: Die Tabelle DBA_XML_TABLES existiert nur bei installierter XML DB. Ohne XML DB kann es keine XMLType Spalten geben.
Tablespace Set überprüfen
Das zu transportierende Tablespace Set (ein oder mehrere Tablespaces) müssen “self-contained” sein. Das bedeutet, dass keine abhängigen Objekte außerhalb der zu exportierenden Tablespaces existieren dürfen.
SQL> execute dbms_tts.transport_set_check('tts', true); PL/SQL-Prozedur erfolgreich abgeschlossen.
Die View TRANSPORT_SET_VIOLATIONS listet alle Abhängigsverletzungen auf.
SQL> select * from transport_set_violations; Es wurden keine Zeilen ausgewahlt
Hinweis: Es können keine Tablespaces mit Objekten des Benutzers SYS, die Tablespaces SYSTEM, SYSAUX und temporäre Tablespaces transportiert werden.
Weitere Informationen zu den Einschränkungen beim Transport von Tablespaces finden sich im Oracle Database Administrator Guide der jeweiligen Datenbankversion (siehe 10g Release 2, 11g Release 2).
Durchführung
Nachdem alle Überprüfungen erfolgreich waren, kann nun mit dem Transport des Tablespaces begonnen werden.
Directory Objekt für Metadaten Export anlegen
Für den Export der Metadaten des Tablespaces mithilfe von DataPump muss ein Directory Objekt in der Datenbank vorhanden sein, das auf einen Dateisystempfad verweist. Ich lege in diesem Beispiel ein neues Directory Objekt an, es kann aber auch ein bestehendes verwendet werden.
Zunächst wird das Verzeichnis im Dateisystem angelegt.
[oracle@rac2 ~]$ mkdir /oracle/tts
Anschließend kann das Directory Objekt mithilfe von SQL*Plus angelegt werden.
SQL> create or replace directory expmetadata as '/oracle/tts'; Verzeichnis wurde erstellt.
Tablespace Read-Only setzen
Für den Transport des Tablespaces muss das zu exportierende Tablespace im Read-Only Modus gesetzt sein.
SQL> alter tablespace tts_data read only; Tablespace wurde geandert.
Hinweis: Das Setzen in den Read-Only Modus kann viel Zeit in Anspruch nehmen, je nach Aktivität des Systems.
Kopie des Tablespaces anlegen
Sollte das Tablespace im ASM oder in einem RAW Device liegen, ist der direkte Zugriff auf die physikalische Datei unter Umständen nicht möglich (z.B. Oracle Version <11g). Aus diesem Grund werde ich mithilfe von rman eine Kopie des Tablespaces erzeugen. Diese wird in dem Verzeichnis /oracle/tts unter dem Namen tts_data.dbf abgelegt.
[oracle@rac2 ~]$ rman Recovery Manager: Release 10.2.0.4.0 - Production on Fri Jan 7 10:07:37 2011 Copyright (c) 1982, 2007, Oracle. All rights reserved. RMAN> connect target connected to target database: TIM (DBID=848962465) RMAN> backup as copy tablespace tts format '/oracle/tts_data.dbf'; Starting backup at 07-JAN-11 using channel ORA_DISK_1 channel ORA_DISK_1: starting datafile copy input datafile fno=00008 name=+DATADG/source/datafile/tts_data.349.739721059 output filename=/oracle/tts_data.dbf tag=TAG20110107T100826 recid=16 stamp=739793316 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:15 Finished backup at 07-JAN-11
Export der Metadaten
Nach dem Backup des Tablespaces können nun die Metadaten des Tablespaces mithilfe von expdp exportiert werden.
[oracle@rac2 ~]$ expdp system/oracle directory=expmetadata dumpfile=tts_data_metadata.dmp transport_tablespaces=tts Export: Release 10.2.0.4.0 - Production on Friday, 07 January, 2011 10:10:59 Copyright (c) 2003, 2007, Oracle. All rights reserved. Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production With the Partitioning, Real Application Clusters, OLAP, Data Mining and Real Application Testing options "SYSTEM"."SYS_EXPORT_TRANSPORTABLE_01": system/******** directory=expmetadata dumpfile=tts_data_metadata.dmp transport_tablespaces=tts wird gestartet Objekttyp TRANSPORTABLE_EXPORT/PLUGTS_BLK wird verarbeitet Objekttyp TRANSPORTABLE_EXPORT/TABLE wird verarbeitet Objekttyp TRANSPORTABLE_EXPORT/TABLE_STATISTICS wird verarbeitet Objekttyp TRANSPORTABLE_EXPORT/POST_INSTANCE/PLUGTS_BLK wird verarbeitet Master-Tabelle "SYSTEM"."SYS_EXPORT_TRANSPORTABLE_01" erfolgreich geladen/entladen ****************************************************************************** Fur SYSTEM.SYS_EXPORT_TRANSPORTABLE_01 festgelegte Dump-Datei ist: /oracle/tts/tts_data_metadata.dmp Job "SYSTEM"."SYS_EXPORT_TRANSPORTABLE_01" erfolgreich um 10:11:51 abgeschlossen
Tablespace Read-Write setzen
Das Tablespace kann nun wieder für Schreibzugriffe geöffnet werden.
SQL> alter tablespace tts_data read write; Tablespace wurde geandert.
Übertragen der Daten auf die Zielseite
Im nächsten Schritt werden nun die Daten des Verzeichnisses /oracle/tts auf die Zielseite kopiert. Dafür kann zum Beispiel WinSCP verwendet werden. Die Daten werden auf der Zielseite im Verzeichnis D:\tts abgelegt.
Directory Objekt für Metadaten Import anlegen
Wie schon auf der Quellseite wird auf der Zielseite ein Directory Objekt benötigt.
C:\Users\Administrator>sqlplus / as sysdba SQL*Plus: Release 11.2.0.1.0 Production on Fr Jan 7 09:55:49 2011 Copyright (c) 1982, 2010, Oracle. All rights reserved. Verbunden mit: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP, Data Mining and Real Application Testing options SQL> create or replace directory impmetadata as 'D:\tts'; Verzeichnis wurde erstellt.
Anlegen des Benutzers in der Zieldatenbank
Alle Benutzer der Quelldatenbank, die Daten in den exportierten Tablespaces besitzen müssen in der Zieldatenbank angelegt werden. Anderenfalls bricht der Import der Metadaten mit einem Fehler ab.
SQL> create user tts_user identified by tts_user; Benutzer wurde erstellt. SQL> grant dba to tts_user; Benutzerzugriff (Grant) wurde erteilt.
Alternativ kann der REMAP_SCHEMA Parameter während des Imports der Metadaten verwendet werden. Dann kann ein bestehender Benutzer der Zieldatenbank verwendet werden.
Konvertieren der Tablespace Kopie und Verschieben in ASM
Das Tablespace muss konvertiert werden, wenn das Endian Format des Quell- und Zielsystems unterschiedlich sind. Anderenfalls braucht eine Konvertierung nicht durchgeführt werden. Ich verwende den rman CONVERT Befehl in diesem Beispiel trotzdem um die Tablespace Kopie in das ASM zu überführen.
C:\Users\Administrator>rman Recovery Manager: Release 11.2.0.1.0 - Production on Fr Jan 7 09:35:22 2011 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. RMAN> connect target Mit Ziel-Datenbank verbunden: TEST (DBID=2037931895) RMAN> convert datafile 'D:\tts\tts_copy.dbf' format '+DATA'; Starten conversion at target um 07.01.11 Kanal ORA_DISK_1 wird benutzt Kanal ORA_DISK_1: Konvertierung von Datendatei wird gestartet Eingabedateiname=D:\TTS\TTS_COPY.DBF Konvertierte Datendatei=+DATA/test/datafile/tts_data.292.739791431 Kanal ORA_DISK_1: Konvertierung von Datendatei abgeschlossen, abgelaufene Zeit: 00:00:47 Beendet conversion at target um 07.01.11
Der neue Name des Datafiles des Tablespaces (+DATA/test/datafile/tts_data.292.739791431) muss sich notiert werden . Dieser wird im nächsten Schritt für den Import der Metadaten benötigt.
Alternativ kann für das Verschieben der Datenbankdatei in die ASM Diskgruppe der cp Befehl des Commadline Werkzeuges ASMCMD verwendet werden. Dies ist aber erst ab Oracle 11g möglich.
Import der Metadaten
Im letzten Schritt werden nun die Metadaten in die Zieldatenbank importiert. Dafür wird impdp verwendet.
C:\Users\Administrator>impdp system/oracle directory=impmetadata dumpfile=tts_data_metadata.dmp transport_datafiles='+DATA/test/datafile/tts_data.292.739791431' Import: Release 11.2.0.1.0 - Production on Fr Jan 7 09:43:04 2011 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. Angemeldet bei: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP, Data Mining and Real Application Testing options Master-Tabelle "SYSTEM"."SYS_IMPORT_TRANSPORTABLE_02" erfolgreich geladen/entladen "SYSTEM"."SYS_IMPORT_TRANSPORTABLE_02": system/******** directory=impmetadata dumpfile=tts_tts.dmp transport_datafiles='+DATA/test/datafile/tts.292.739791431' wird gestartet Objekttyp TRANSPORTABLE_EXPORT/PLUGTS_BLK wird verarbeitet Objekttyp TRANSPORTABLE_EXPORT/TABLE wird verarbeitet Objekttyp TRANSPORTABLE_EXPORT/POST_INSTANCE/PLUGTS_BLK wird verarbeitet Job "SYSTEM"."SYS_IMPORT_TRANSPORTABLE_02" erfolgreich um 09:45:05 abgeschlossen
Überprüfung der Daten
Zum Abschluss dieses Artikels überprüfe ich die importierten Daten.
C:\Users\Administrator>sqlplus / as sysdba SQL*Plus: Release 11.2.0.1.0 Production on Fr Jan 7 09:55:49 2011 Copyright (c) 1982, 2010, Oracle. All rights reserved. Verbunden mit: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP, Data Mining and Real Application Testing options SQL> select * from v$tablespace; TS# NAME INC BIG FLA ENC --- ------------------------------ --- --- --- --- 0 SYSTEM YES NO YES 1 SYSAUX YES NO YES 2 UNDOTBS1 YES NO YES 3 TEMP NO NO YES 4 UNDOTBS2 YES NO YES 5 USERS YES NO YES 6 TTS_DATA YES NO YES 7 Zeilen ausgewählt. SQL> connect tts_user/tts_user Connect durchgeführt. SQL> select count(*) from sys_obs; COUNT(*) ---------- 6929
Wie die beiden SQL Queries zeigen wurde das Tablespace erfolgreich importiert. Es steht auch die angelegte Tabelle SYS_OBS mit allen eingefügten Zeilen zur Verfügung. Der Transport war erfolgreich.