Oracle Plattform Migration cross platform transportable tablespaces (XTTS) Methode und Erfahrungsbericht

Transkript

1 Oracle Plattfrm Migratin crss platfrm transprtable tablespaces (XTTS) Methde und Erfahrungsbericht Jsef Lippert Freiberuflicher IT Cnsultant München Schlüsselwrte: Migratin, Transprtable Tablespace, Transprtable Database, RMAN Einleitung Oracle Plattfrm Migratin ermöglicht das Verschieben der Datenbank zwischen verschiedenen Betriebs- und Hardware-Systemen. Der herkömmliche Weg über Exprt/Imprt/DataPump der Daten birgt ein erhebliches zeitliches Risik. Mit dem Oracle Data Guard steht eine weitere Migratinsmethde zur Verfügung, die aber nur bei unterstützten Plattfrmen möglich ist und das gleiche endian - Frmat aufweisen. Siehe hierzu: Data Guard Supprt fr Hetergeneus Primary and Physical Standbys in Same Data Guard Cnfiguratin [ID ] Transprtable Tablespaces sind seit Oracle 8i verfügbar und wurden seitdem stetig funktinal erweitert. Mit Oracle 10g R2 wurden transprtable database (TDB) und crss platfrm transprtable tablespaces (XTTS) eingeführt. Letztere erlaubt neben der Datenmigratin auch eine Datenknvertierung unterschiedlicher endian -Typen. Die Datenknvertierung ist z. B. zwischen HP-UX/Slaris/AIX und Linux/Windws erfrderlich. Während der Migratin steht die Surce-Datenbank Read Only zur Verfügung. Migratinsmethde - XTTS Flgende Idee liegt der Migratinsmethde zu Grunde (siehe Abb. 1): Neue, leere Datenbank auf dem Zielsystem anlegen Meta-Daten extrahieren Nutz-Daten für Zielplattfrm knvertieren (siehe Abb. 2) Nutz-Daten (User-Tablespaces) transprtieren Meta-Daten imprtieren

2 Abb. 1: Arbeitsweise crss platfrm transprtable tablespaces (XTTS) Abb. 2: Endian Typen

3 CONVERT DATAFILE '/racle/src/tls01.dbf', '/racle/src/user01.dbf', FROM PLATFORM 'Linux x86 64-bit' PARALLELISM 2 DB_FILE_NAME_CONVERT '/racle/src', '/racle/tgt' Abb. 3: Beispiel RMAN Knvertierung Migratins-Arbeitsschritte im Einzelnen Ziel-Datenbank mit allen genutzten Optinen und entsprechenden Character-Set/Natinal- Character-Set aufbauen InSurce-Datenbank: Analyse, b Tablespace im Set transprtiert werden kann (siehe Abb. 4) invalide Objekte kmpilieren Recyclebin leeren In Surce-Datenbank Tablespaces Read Only setzen Evtl. Sequence Infrmatinen ermitteln Externe File: dbms_tdb.check_external, dbms_lb.filegetname Meta-Daten exprtieren Nn-Segment User Daten exprtieren Weitere Daten (z. B. AWR) exprtieren (siehe Abb. 5) Create-Skripte für Rllen und User erzeugen Evtl. create-skripte für Advanced Queueing Settings In Ziel-Datenbank: Filesysteme via NFS munten Datenfiles via RMAN knvertieren User und Rllen anlegen Meta-Daten imprtieren Nn-Segment User Daten imprtieren Evtl. weitere Daten imprtieren (AWR, ) Evtl. Advanced Queueing Settings, etc. Evtl. Sequence Infrmatin anpassen Parameter Dateien, externe Tabellen, bfiles, etc. anlegen/transferieren startup upgrade mit utlirp.sql und utlrp.sql Daten/Inhaltsvergleich zwischen Surce- und Ziel-DB durchführen tnsnames/ldap anpassen

4 SQL> exec dbms_tts.transprt_set_check('tools, USERS',TRUE,TRUE); SQL> select * frm transprt_set_vilatins; VIOLATIONS ORA-39908: Index DEFUSER.TEST_PK in tablespace IDXTSP enfrces primary cnstraints f table DEFUSER.ORA_TEST_TEMPLATE in tablespace TOOLS. Abb. 4: Tablespace Transprt-Anhängigkeit prüfen Abb. 5: V$SYSAUX_OCCUPANT_NAME Mve prcedures Limitierungen der Migratinsmethde In Surce-und Ziel-Datenbank müssen der Character-Set, Natinal-Character-Set, cmpatible -Parameter swie die Oracle Optinen identisch sein Encryptin-Clumns werden nicht unterstützt Migratins-Tablespaces müssen self-cntained sein Advanced Queue Einstellungen werden nur teilweise migriert Binary_Flat and Binary_Duble nur mit Datapump Tabellen auf den Tablespaces SYSTEM, UNDO, SYSAUX und TEMP können nicht transprtiert werden

5 Externe Objekte (parameter files, external tables, bfiles, etc.) müssen manuell bewegt werden SYS Objekte (packages, views, java classes, sequences, etc.) werden nicht transprtiert Erfahrungsbericht Die XTTS-Methde wurde bislang auf ca. 100 Datenbanken unterschiedlicher Größen vn 5 GB bis 2 TB erflgreich angewandt. Für alle aufgetretenen Umstände knnte eine Lösung/Wrkarund gefunden werden. Wichtig hier ist, im Vrfeld die Surce-Datenbank stets hinsichtlich bekannter Prbleme zu untersuchen. Hierzu zählen typische bekannte Oracle Bugs der Erkenntnisse, die sich während der Migratin selbst ergeben. Flgende Fehler/Prbleme/Bugs traten auf und verlangten händische -Eingriffe: (Anmerkung: Die Aufzählung erhebt keinen Anspruch auf Vllständigkeit und ist vm Oracle Release-Stand abhängig.) Tabellen mit dem Datentyp ROWDEPENDENCIES Patch muss eingebracht sein Tabellen mit dem Datentyp BINARY_FLOAT und BINARY_DOUBLE nur" mit Datapump zu bewegen Oracle Text-Objekte auf dem Tablespace SYSAUX Siehe V$SYSAUX_OCCUPANT_NAME Oracle Text User Index Preferences u. U. manuelle Nacharbeiten XML Data In 10g nur" mit exprt/imprt zu bewegen Indexe auf Temp-Tables In 10g nicht mit transprtiert Kmprimierte Tabellen Krruptinen traten auf Advanced Queueing Settings u. U. manuelle Nacharbeiten RMAN: CONFIGURE DEVICE TYPE DISK PARALLELISM Device Type muss Disk sein

6 Für die Migratin selbst wurde auf der Ziel-Datenbank db_blck_checking und db_blck_checksum eingeschaltet um ptentielle Datenkrruptinen rechtzeitig zu entdecken. Aus Perfrmancegründen ist im Nachgang der Parameter db_blck_checking zu deaktivieren. Die Migratinsdauer wird vn mehreren Größen beeinflusst: Größe des Data-Dictinary z. B. Partitining Optin CPU-Perfrmance für die endian -Typ-Knvertierung mit dem RMAN Parallelität der Knvertierung Perfrmance I/O Subsystem z. B. FILESYSTEMIO_OPTIONS = { nne setall directio asynch } Netz-Perfrmance für den Filetransfer Einsatz vn huge pages prüfen Nach der Migratin empfiehlt sich u. a. das DB Cache Sizing zu betrachten, da dies u. U. auf den verschiedenen Plattfrmen unterschiedlich behandelt wird. Ein möglicher Ansatzpunkt ist der Cache Advisr: alter system set db_cache_advice = n scpe=memry; SELECT size_fr_estimate, buffers_fr_estimate, estd_physical_read_factr, estd_physical_reads/1000 FROM v$db_cache_advice WHERE advice_status = 'ON';

7 Abb. 6: v$db_cache_advice Methdischer Ablaufplan Abb. 7: Ablaufplan

8 Fallback Szenarien Szenari 1: Die Surce-Datenbank wird inhaltlich nicht mdifiziert. Während der Migratin werden die User-Tablespace auf Read Only gesetzt und müssen smit beim Fallback nur wieder auf Read Write gebracht werden. D. h. in relativ kurzer Zeit steht das Ausgangssystem unverändert wieder zur Verfügung. Zu beachten ist aber, dass nach dem Fallback die im neuen Zielsystem bereits mdifizierten Daten verlren sind. Szenari 2: Dieses Szenari bietet sich an, wenn die Daten in der Ziel-Datenbank bereits erheblich mdifiziert wurden. Durch Rück-Knvertierung der Ziel-Datenbank mittels der gleichen Migratinsmethde werden die mdifizierten Daten in die Ausgangsdatenbank gebracht. Hierdurch entsteht aber eine erneute Dwntime swie ein meist hhes Risik, da dieser Rückweg ft nicht hinreichend getestet beschritten wird. Kntaktadresse: Name Jsef Lippert IT Beratung München Telefn: +49 (0) Internet: