Transportable Tablespace über verschiedene Plattformen
___________________________________________________
In unserem Beispiel transportieren wir einen Tablespace namens TEST. Der Tablespace sollte in sich geschlossen sein, ohne dass Objekte auf andere Tablespaces verweisen, also überprüfen Sie, ob der Tablespace in sich geschlossen ist, indem Sie die folgende Abfrage verwenden:
FÜHREN SIE dbms_tts AUS.transport_set_check(‚TEST‘, TRUE, TRUE);
WÄHLEN SIE * AUS transport_set_violations;
Wenn Sie Querverweise auf Objekte haben. Löschen Sie diese Objekte aus dem TEST-Tablespace (Bitte beachten Sie, dass dies in einer Testumgebung erfolgt, damit ich die Objekte mit Querverweisen problemlos löschen kann. Lassen Sie keine Objekte fallen, ohne Ihren leitenden DBA in einer Produktionsumgebung zu konsultieren. Man weiß nie, welches Objekt welche Abhängigkeit hat. Angenommen, Sie haben Indizes im TEST-Tablespace, die auf Tabellen in einem anderen Tablespace verweisen. Sie können diese Indizes sicher mit der folgenden PL / SQL-Prozedur verschieben:
begin
for c1 in (select index_name a1 from user_indexes)
loop
execute immediate ‚alter index ‚||c1 .a1 ||‘ Online-Tablespace neu erstellen < Tablespace-Name >‘;
Endschleife;
Ende;
/
Fahren Sie nun fort und überprüfen Sie die Verstöße erneut. Wenn Sie einen Fehler wie:
SELECT * FROM transport_set_violations;
VERSTÖßE
—————————
Verstoß 46 : Oracle-Support kontaktieren
Verstoß 46 : Oracle-Support kontaktieren
Verstoß 46 : Oracle Support kontaktieren
Führen Sie diese Abfrage aus, um zu überprüfen, warum der Verstoß ausgelöst wird
SELECT TRIM(OBJ1_OWNER) || ‚, ‚ || TRIM(OBJ1_NAME) || ‚, ‚ ||
TRIM(OBJ1_SUBNAME) |/ ‚, ‚ |/ TRIM(OBJ1_TYPE) || ‚, ‚ ||
TRIM(TS1_NAME) |/ ‚, ‚ |/ TRIM(TS2_OWNER) || ‚, ‚ ||
TRIM(OBJ2_NAME) |/ ‚, ‚ |/ TRIM(OBJ2_SUBNAME) || ‚, ‚ ||
TRIM(TS2_TYPE) || ‚, ‚ || TRIM(TS2_NAME) || ‚, ‚ ||
TRIM(CONSTRAINT_NAME) |/ ‚, ‚ |/ TRIM(GRUND)
VON PLUGGABLE_SET_CHECK
WHERE MESG_ID=46;
Dadurch wird ausgegeben, was genau die Verletzung für den transportierbaren Tablespace ist. Beheben Sie diese Verstöße und starten Sie das eigentliche Verfahren zum Transportieren des Tablespace. In meinem Beispiel hatte ich transparente Datenverschlüsselung (TDE) für einige Spalten in der Datenbank verwendet. In der Abfrage wurde gemeldet, dass Sie TT_TBS nicht verwenden können, wenn Sie Spalten verschlüsselt haben. Also musste ich die Spalten entschlüsseln, die ich mit einer Abfrage wie verschlüsselt habe.
SELECT * FROM dba_encrypted_columns;
TABELLE ÄNDERN Konto ÄNDERN (Karteninhaber ENTSCHLÜSSELN);
Nach dem Entschlüsseln der Spalten. Wir gehen weiter
1. Überprüfen Sie die ENDIAN-Version von Quelle und Ziel mithilfe des folgenden Skripts:
—
— Welche Möglichkeiten gibt es für die Transportable Tablespace-Plattform?
—
SELECT
platform_name
,endian_format
FROM v$transportable_platform
SORTIEREN NACH platform_name
;
—
— Wie ist die aktuelle ENDIANITÄT meiner Datenbank und Plattform?
—
SELECT
D.name
,TP.endian_format
VON
v$transportable_platform TP
,v$database D
WOBEI TP.platform_name = D.platform_name
;
Es wird gemeldet, ob der ENDIAN „klein“ oder „groß“ ist. Wenn der Endian auf Ziel und Quelle gleich ist, muss kein transportabler Tablespace verwendet werden. Sie können den Tablespace einfach exportieren und in das Ziel importieren. Wenn nicht, fahren Sie wie unten
2 fort. Ändern Sie den Tablespace und versetzen Sie ihn in den schreibgeschützten Modus für die Quelle. In unserem Beispiel transportieren wir einen Tablespace namens TEST zum Zielserver.
ALTER TABLESPACE test SCHREIBGESCHÜTZT;
3. exportieren Sie nun die Tablespace-Metadaten.
## Windows###
exp USERID=’system / oracle@Source ALS SYSDBA‘ TRANSPORT_TABLESPACE= y TABLESPACES=Testdatei =test_repository.dmp log=test_repository.txt
### Unix###
exp \’sys/oracle ALS SYSDBA\‘ TRANSPORT_TABLESPACE=y TABLESPACES=Testdatei=test_repository.dmp log=test_repository.txt
Gehen Sie zu target und kopieren Sie die Dumpfile zusammen mit den Datendateien dieses Tablespace an einen beliebigen Speicherort.
imp \’sys/oracle ALS SYSDBA\‘ TABLESPACES=test TRANSPORT_TABLESPACE=y DATEI=test_repository.dmp datafiles=’users_01.dbf‘
4. Das obige gilt, wenn Sie einen Tablespace auf einen Computer mit denselben Endian-Informationen exportieren. Wenn Sie einen anderen Endian verwenden, gehen Sie wie folgt vor. Wir werden von Solaris 64-Bit SPARC (BIG) auf Windows 32-Bit (Little)
5 konvertieren. Konvertieren Sie die Datendateien mit RMAN und db_file_name_convert
# verwenden Sie diese Methode nicht: Auf dem Quellcomputer: Mit dem ursprünglichen Dateinamen
RMAN> Konvertieren Sie den Tablespace ‚TEST‘
in die Plattform ‚Microsoft Windows IA (32-Bit)‘
format=’/datafiles/rmanbkp/%N_%f‘
Parallelität = 4;
## verwenden Sie diese Methode: Auf Quellcomputer: Mit konvertiertem Dateinamen Dateiname
RMAN> Konvertieren Sie den Tablespace ‚TEST‘
2> in die Plattform ‚Microsoft Windows IA (32-Bit)‘
3> db_file_name_convert ‚/datafiles/oradata/SWX‘,’/datafiles/rmanbkp‘
4> Parallelität = 4;
Nachdem die Dateien konvertiert wurden, finden Sie sie in ‚/ datafiles / rmanbkp‘. Kopieren Sie diese konvertierten Dateien zusammen mit dem Metadaten-Dump von TT_TBS, legen Sie sie auf den Quellserver und führen Sie den Import aus:
imp USERID=’system/Passwort@Ziel ALS SYSDBA‘
TRANSPORT_TABLESPACE=y
DATAFILES=’C:\datafiles\test01.DBF‘,’C:\datafiles\test02.DBF‘
TABLESPACES=test
DATEI=test_repository.dmp
In den obigen Fällen haben wir die Dateien auf der Quellplattform konvertiert. Sie können dies jedoch auch auf der Zielplattform tun. Sie können beispielsweise die Datei test01 kopieren.dbf zusammen mit dem Metadaten-Dump auf einem 32-Bit-Zielcomputer von Windows Server 2003 und konvertieren Sie es dort:
RMAN> konvertieren
2> Datendatei ‚c:/users01.dbf‘ ##Verzeichnis, in das Sie Ihre Datendatei vom Quellserver
3> Format ‚c:/datafiles/rmanbkp/%N_%f ‚ ##Verzeichnis, in dem Sie die konvertierte Datei erhalten
4> ;
Dieser Ansatz erstellt eine Datei in dem im Verzeichnis angegebenen Format.
Aber warum sollten Sie die Datendateien genau auf der Zielplattform konvertieren? Ein Grund könnte eine kürzere Ausfallzeit sein, bei der die Tablespaces nur für die Dauer der Kopie auf den Zielhost SCHREIBGESCHÜTZT sein müssen. Sie können die Datendatei dreifach spiegeln, den Tablespace schreibgeschützt machen, den dritten Spiegel unterbrechen und den Tablespace sofort zum Lesen / Schreiben bringen. Dieser dritte Spiegel könnte dann auf dem Zielsystem montiert und nach Belieben umgebaut werden. Diese Anordnung minimiert die Dauer, für die der Tablespace schreibgeschützt bleiben muss.
Ein weiterer Grund könnte die Leistung sein. Die OLTP-Datenbank kann unter einer konstanten Last stehen und die Verwendung der RMAN-Konvertierungsoperation kann das System mehr als gewünscht belasten. Stattdessen kann die Konvertierung auf den Data-Warehouse-Server ausgelagert werden, wo in der Regel mehr CPUs für parallele Operationen zur Verfügung stehen.
