Oracle Datenbank-Migration<br />Düsseldorf, 17. März 2011<br />Oracle 11gR2 Erfahrungen <br />Christian BallwegSenior Cons...
Agenda<br />Migrationsvarianten und Begriffe<br />Migration durch Import in neueDatenbank<br />Hardware-Migration mitÜbern...
Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.
Die  Standardfarben sind:</li></li></ul><li>1<br />Migrationsvarianten und Begriffe<br />Design:<br /><ul><li>Das Farbsche...
Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.
Die  Standardfarben sind:</li></li></ul><li>Migrationsvarianten, Begriffe<br />Datenbank-Upgrade<br />Austausch der Softwa...
Migrationsvarianten<br />Was wollen wir migrieren?<br />Lösungswege?<br />Versions-Upgrade<br />ja<br />nein<br />Hardware...
2<br />Migration durchImport in neue Datenbank<br />Design:<br /><ul><li>Das Farbschema ist im Design als „OC 2009“ hinter...
Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.
Die  Standardfarben sind:</li></li></ul><li>Import in neue Datenbank<br />Neue Datenbank aufbauen und Daten importieren mi...
Plattform-unabhängig
Langsam (kein direct-path-load, keine Parallelisierung)
Keine Erzeugung einzelner User (nur bei Full-Import)</li></ul>Oracle Datapump expdp / impdp Utility<br /><ul><li>Gleiche V...
Erst ab Oracle 10g verfügbar
Nicht alle Datentypen korrekt unterstützt (insb. bei Datapump über NETWORK_LINK)</li></ul>Aufgrund von Datentyp-Problemen ...
Generell: keine (eigenen) Objekte unter SYS!</li></ul>Export<br />Import<br />
Import in neue Datenbank<br />Neue Datenbank aufbauen und Daten importierenmit Oracle Mitteln und eigenen Scripts<br />sql...
Parallelisierbar
Nur Datenübernahme, Scripts für Erstellung und Transfer selbst zu implementieren</li></ul>Database-Link<br />create table ...
Import in neue Datenbank<br />Neue Datenbank aufbauen und Daten importieren mit Zusatzsoftware<br />Eventuell applikatoris...
Signifikante Kosten</li></ul>Quest Shareplex<br /><ul><li>Simples Handling für Migrationszwecke
Kosten & Beschränkung auf Oracle</li></ul>Generelle Vor- und Nachteile<br />Vorteile: <br /><ul><li>Gleichzeitige Migratio...
Neu aufgebaute, reorganisierte Datenbank, Nutzung aller neuen Features möglich
Plattformunabhängig</li></ul>Nachteile: <br /><ul><li>Langsam; insbesondere der Aufbau von Indexen kann sehr lange dauern
User, Rollen, Objekte müssen neu erstellt werden</li></li></ul><li>3<br />Hardware-Migration mit Übernahme der Datenbank<b...
Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.
Die  Standardfarben sind:</li></li></ul><li>Hardware-Migration mit Übernahme der DB<br />Kopieren der bestehenden Datenban...
Risikoarm, da keine Änderung an der Datenbank
Downtime für die Zeit des Kopierens
Nur innerhalb der gleichen Plattform
Kein Upgrade der Oracle Version
Keine Reorganisation der Daten/Indizes</li></ul>copy<br />
Hardware-Migration mit Übernahme der DB<br />Migration mit Transportable Database<br />Erfolgt über RMAN<br /><ul><li>Gesa...
Gewisse Plattform-Migrationen sind möglich
Nächste SlideShare
Wird geladen in …5
×

Datenbank Migration - Oracle 11gR2 Erfahrungen 2011 - OPITZ CONSULTING - Christian Ballweg

7.396 Aufrufe

Veröffentlicht am

Der Vortrag zum Thema Migration war Teil der OPITZ CONSULTING Veranstaltungsreihe zum Thema Oracle 11gR2 Erfahrungen an verschiedenen Standorten unserer IT-Beratung. Die Migration von Datenbanken erfolgt aus verschiedenen Gründen: Für die eine Datenbank wurde der Wechsel der Hardware-Architektur oder der Austausch des Betriebssystems beschlossen. Eine zweite Datenbank soll an die neueste Version der Datenbank-Software angepasst werden. Die dritte Datenbank wird von einem Test- in ein Produktivsystem übernommen. Der Referent Christian Ballweg klärt die Begriffe Migration und Upgrade und zeigt Möglichkeiten der Übernahme einer Datenbank auf neue Plattformen durch die Techniken Import, Transportable Tablespaces und Data Guard. Dabei werden Vor- und Nachteile sowie die erforderliche Downtime betrachtet.

Veröffentlicht in: Technologie, News & Politik
0 Kommentare
2 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
7.396
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
2
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
2
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie
  • Der Begriff Upgrade wird hier verwendet für den Wechsel des Oracle Releases, z.B. 9i  11g oder 11.2.0.1  11.2.0.2Der Begriff Migration wird hier verwendet für den Wechsel der Hardware. Die Migration kann mit einem Upgrade kombiniert werden.Plattform: Kombination von Hardware und Betriebssystem, z.B. Linux x86, Linux Itanium, Solaris Sparc, Solaris x86Little/Big-Endian: Datafiles können nicht direkt übernommen werden, wenn die andere Plattform ein anderes Endian-Format hat.Downtime: Wie können wir die Downtime bei der Migration reduzieren? Zeit der Migration ist nicht zwingend gleich der Downtime.
  • Erklären, welche Möglichkeiten es gibt. Im Beispiel dargestellt. Kein-SW-Upgrade, Plattform-Wechsel ohne Endianness-Wechsel (z.B. Windows auf Linux  Migration mit DataGuardWeitere Beispiele nennen: Software-Upgrade mit Plattformtausch mit Endian-Welchsel: z.B. mit Transportable Tablespace, wenn &gt; 10g, ansonsten zuerst Upgrade auf alter Software auf 10g, dann TTS
  • Problematisch ist exotisches Zeug wie xml, eigene Datentypen, Objekt-Tabellen usw. Manchmal funktioniert es nur mit exp, manchmal nur mit expdp. Besonders problematisch sind spezielle Objekte bei Datapump über NETWORK_LINK (LONGs, OBJECT_TYPE columns, PARTITIONS, ...).Kein direct_path (bei impdp) wenn: LOBs, global index auf partitionedtable, supplementallogging, …Eigene Objekte, welche unter sys erstellt wurden, werden nicht exportiert!
  • Vornehmlich ERGÄNZEND:GoldenGate erlaubt auch vorherigen Aufbau ohne downtime mit Replizierung, ähnlich wie eine logicalstandby – aber nur ohne LOBs! Shareplex hat spezielle Features wie „live-Activation“ und „flushqueue“: leeren der Puffer mit abschließender Abschaltung des Apply-Prozesses
  • DataGuard (phys/log)Mittelder Wahl!TDB: “Use transportable database for platform migration only when cross-platform physical standby database or logical standby database is not supported for the platform combination in question. […] There is less downtime (only the time it takes to switchover) and it is possible to run the standby database on the new platform temporarily to ensure that everything is working as planned.”
  • MASTER NOTE: 1166564.1select * fromv$transportable_platform;10G:Solaris[tm] OE (32-bit) BigSolaris[tm] OE (64-bit) BigMicrosoft Windows NT LittleLinux IA (32-bit) LittleAIX-Based Systems (64-bit) BigHP-UX (64-bit) BigHP Tru64 UNIX LittleHP-UX IA (64-bit) BigLinux IA (64-bit) LittleHP Open VMS LittleMicrosoft Windows IA(64-bit) LittleIBM zSeriesBased Linux BigLinux 64-bit for AMD LittleApple Mac OS BigMicrosoft Windows 64-bit for AMD LittleHier (bzw. nach den nächsten 2 Folien) kann eine kleine Demo stattfinden, Migration von AIX nach Linux (32 oder 64bit, bestehende Datenbank verwenden)
  • Nicht auf Details eingehen, nur den Teilnehmern das Grobkonzept in Erinnerung rufen, was die Idee hinter Dataguard ist.Wenn Konzept schon im Vortrag Verfügbarkeit erwähnt wurde, Folie überspringen.
  • Wichtig: die rot markierten BegriffePlattform: 1) gleiches CD-Set (siehe Bild) PLUS2) gleiche Platform_IDMOS-Notes Stand Februar 2011. Kann gelegentlich ändern (z.B. ist Solaris x86  Linux im Vergleich zur Version von Anfang 2010 hinzugekommen)
  • Hellgrün: auf gleicher Plattform ist immer supported
  • Der Aufbau auf Linux 64Bit kann eventuell etwas Handarbeit erfordern. (db_file_name_convert funktioniert möglicherweise nicht korrekt). Auf 32bit jedoch keine solchen Probleme gesehen. Siehe Vortrag &quot;Migration mit DataGuard&quot; vom letzten Jahr (basierte aber noch auf 11.1).
  • Auf diese Folie nur kurz eingehen, wird in den folgenden Graphiken erklärt.UNSUPPORTED in LSB (9i): IOTs, Userdef. Tables, Tables w/ FBIs, Sequences in SYS-Schema…  select DBA_LOGSTDBY_UNSUPPORTEDLONGLONG RAWBFILENCLOBROWIDUROWIDUser-definedtypesObjecttyoes REFsVarryasNestedtables…
  • Es sind nur wenige Kombinationen unterstützt. Man beachte, dass nur 3264bit, nicht aber 6432bit möglich ist
  • Es sind nur wenige Kombinationen unterstützt. Man beachte, dass nur 3264bit, nicht aber 6432bit möglich ist
  • Datenbank Migration - Oracle 11gR2 Erfahrungen 2011 - OPITZ CONSULTING - Christian Ballweg

    1. 1. Oracle Datenbank-Migration<br />Düsseldorf, 17. März 2011<br />Oracle 11gR2 Erfahrungen <br />Christian BallwegSenior ConsultantOPITZ CONSULTING Essen GmbH<br />
    2. 2. Agenda<br />Migrationsvarianten und Begriffe<br />Migration durch Import in neueDatenbank<br />Hardware-Migration mitÜbernahmederDatenbank<br />Migration/Upgrade mit Transportable Tablespace<br />Hardware-Migration mit Data Guard<br />Datenbank-Upgrade mit "Rolling Migration"<br />Fazit<br />Design:<br /><ul><li>Das Farbschema ist im Design als „OC 2009“ hinterlegt.
    3. 3. Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.
    4. 4. Die Standardfarben sind:</li></li></ul><li>1<br />Migrationsvarianten und Begriffe<br />Design:<br /><ul><li>Das Farbschema ist im Design als „OC 2009“ hinterlegt.
    5. 5. Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.
    6. 6. Die Standardfarben sind:</li></li></ul><li>Migrationsvarianten, Begriffe<br />Datenbank-Upgrade<br />Austausch der Software (ORACLE_HOME) durch neuere Version<br />Anpassen DataDictionary (catupgrd.sql)<br />Dauer abhängig von Hardware und Anzahl der Datenbank-Objekte<br />Hardware-Migration/Plattform-Migration<br />Transfer der Datenbank auf einen anderen Server<br />Gleiche Architektur, gleiche Betriebssystem-Familie (z. B. SuSE  RedHat)<br />Gleiche Architektur, anderes Betriebssystem (z. B. Windows  Linux)<br />Andere Architektur, anderes Betriebssystem (z. B. AIX  Linux)<br />Kombination von DB-Upgrade mit Hardware-Migration<br />Little-/Big-Endian<br />Angabe, wo im Speicher das höchstwertige Byte steht<br />Bsp: „Motorola-Format“  Big-Endian, „Intel-Format“  Little-Endian<br />Downtime<br />Zeit, während dem kein Client-Zugriff möglich ist. Wie minimieren?<br />
    7. 7. Migrationsvarianten<br />Was wollen wir migrieren?<br />Lösungswege?<br />Versions-Upgrade<br />ja<br />nein<br />HardwareAustausch<br />HardwareAustausch<br />ja<br />ja<br />nein<br />nein<br />Plattform-Austausch<br />Plattform-Austausch<br />catupgrd.sql<br />fertig <br />ja<br />nein<br />ja<br />nein<br />Endian-Wechsel<br />nein<br />ja<br />...<br />...<br />...<br />11g<br />...<br />DataGuard<br />
    8. 8. 2<br />Migration durchImport in neue Datenbank<br />Design:<br /><ul><li>Das Farbschema ist im Design als „OC 2009“ hinterlegt.
    9. 9. Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.
    10. 10. Die Standardfarben sind:</li></li></ul><li>Import in neue Datenbank<br />Neue Datenbank aufbauen und Daten importieren mit Oracle Mitteln<br />Oracle exp / impUtility<br /><ul><li>In allen Oracle Versionen verfügbar
    11. 11. Plattform-unabhängig
    12. 12. Langsam (kein direct-path-load, keine Parallelisierung)
    13. 13. Keine Erzeugung einzelner User (nur bei Full-Import)</li></ul>Oracle Datapump expdp / impdp Utility<br /><ul><li>Gleiche Vorteile wie exp/imp& schneller als exp/imp (direct-path-load, Parallelisierung)
    14. 14. Erst ab Oracle 10g verfügbar
    15. 15. Nicht alle Datentypen korrekt unterstützt (insb. bei Datapump über NETWORK_LINK)</li></ul>Aufgrund von Datentyp-Problemen ggf. Kombination beider Tools<br /><ul><li>Problematisch: LONGs, Object-/XMLType.Columns, PARTITIONs, …  prüfen!
    16. 16. Generell: keine (eigenen) Objekte unter SYS!</li></ul>Export<br />Import<br />
    17. 17. Import in neue Datenbank<br />Neue Datenbank aufbauen und Daten importierenmit Oracle Mitteln und eigenen Scripts<br />sqlplus und sqlloader<br />Exportieren als Flat-file mit sqlplus, importieren mit sqlloader<br /><ul><li>Direct Path Import
    18. 18. Parallelisierbar
    19. 19. Nur Datenübernahme, Scripts für Erstellung und Transfer selbst zu implementieren</li></ul>Database-Link<br />create table as select ...<br />Etwa gleiche Vor- und Nachteile wie bei sqlplus/sqlldr<br />
    20. 20. Import in neue Datenbank<br />Neue Datenbank aufbauen und Daten importieren mit Zusatzsoftware<br />Eventuell applikatorischer Datentransfer<br />Oracle GoldenGate (Von Oracle gekaufte Replikationslösung)<br /><ul><li>Nicht auf Oracle Datenbanken beschränkt
    21. 21. Signifikante Kosten</li></ul>Quest Shareplex<br /><ul><li>Simples Handling für Migrationszwecke
    22. 22. Kosten & Beschränkung auf Oracle</li></ul>Generelle Vor- und Nachteile<br />Vorteile: <br /><ul><li>Gleichzeitige Migration auf neuere Datenbank möglich
    23. 23. Neu aufgebaute, reorganisierte Datenbank, Nutzung aller neuen Features möglich
    24. 24. Plattformunabhängig</li></ul>Nachteile: <br /><ul><li>Langsam; insbesondere der Aufbau von Indexen kann sehr lange dauern
    25. 25. User, Rollen, Objekte müssen neu erstellt werden</li></li></ul><li>3<br />Hardware-Migration mit Übernahme der Datenbank<br />Design:<br /><ul><li>Das Farbschema ist im Design als „OC 2009“ hinterlegt.
    26. 26. Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.
    27. 27. Die Standardfarben sind:</li></li></ul><li>Hardware-Migration mit Übernahme der DB<br />Kopieren der bestehenden Datenbank<br />Via Netzwerk (NFS, SMB, scp, ftp, ...) oder SAN<br /><ul><li>Vorteil: bei Misserfolg steht alte Umgebung noch zur Verfügung</li></ul>Verschieben des bestehenden Storage auf neuen Server<br />Physischer Transfer der Disks<br />Oder: Umhängen der LUN's im SAN<br />Vor- und Nachteile<br /><ul><li>Technisch einfach
    28. 28. Risikoarm, da keine Änderung an der Datenbank
    29. 29. Downtime für die Zeit des Kopierens
    30. 30. Nur innerhalb der gleichen Plattform
    31. 31. Kein Upgrade der Oracle Version
    32. 32. Keine Reorganisation der Daten/Indizes</li></ul>copy<br />
    33. 33. Hardware-Migration mit Übernahme der DB<br />Migration mit Transportable Database<br />Erfolgt über RMAN<br /><ul><li>Gesamter Inhalt, inkl. User, Prozeduren usw. wird übernommen
    34. 34. Gewisse Plattform-Migrationen sind möglich
    35. 35. Nur für Plattformen desselben Endian-Formats
    36. 36. Erst ab Oracle 10g
    37. 37. Downtime für den Transport ist größer als mittels DataGuard</li></li></ul><li>4<br />Hardware- / Plattform-Migration mit Transportable Tablespace<br />Design:<br /><ul><li>Das Farbschema ist im Design als „OC 2009“ hinterlegt.
    38. 38. Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.
    39. 39. Die Standardfarben sind:</li></li></ul><li>Hardware- / Plattform-Migration mit Transportable Tablespaces<br />Neue Datenbank aufbauen und Tablespaces übernehmen<br />Applikations-Tablespaces können an neue Datenbank "angehängt" werden<br />Tabellen mit Daten werden übernommen<br />Aber: Keine User, Prozeduren usw.  z.B. mit impdp übernehmen<br />Verwendung der Funktionalität "Transportable Tablespaces" <br />Vorteile <br /><ul><li>funktioniert auch über Plattformgrenzen little-/big-Endian hinweg (RMAN – erst ab 10g)convert datafile '/oradata/aix.dbf' from platform 'AIX-Based Systems (64-bit)' format '/oradata/linux.dbf';
    40. 40. Datenbank-Upgrade möglich
    41. 41. Fallback auf alten Server möglich</li></ul>Nachteile<br /><ul><li>Nicht möglich für SYSTEM Tablespace und Objekte die SYS gehören
    42. 42. User und Prozeduren (deren Information in SYS-Tabellen liegen) müssen zuvor erstellt werden</li></li></ul><li>Migration/Upgrade mit Transportable Tablespace<br />Vorbereiten eines neuen Servers mit neuer Datenbank<br />Erstellen User, Packages, Grants usw. auf neuem Server<br />ohne Tabelleninhalt<br />old server, productive DB<br />new server, empty database<br />system<br />system<br />undo<br />undo<br />temp<br />temp<br />application1<br />application2<br />expdp content=metadata_only<br />old server, productive DB<br />new server, empty database<br />system<br />system<br />undo<br />undo<br />temp<br />temp<br />application1<br />application2<br />impdp include=schema ...<br />
    43. 43. Migration/Upgrade mit Transportable Tablespace<br />Transferieren der Tablespaces (mit Metadaten)<br />Importieren der transportierten Tablespaces<br />Gegebenenfalls vorher rman convert datafile<br />expdp transport_tablespaces=application1,...<br />Old Server<br />New Server, Empty Database<br />system<br />system<br />undo<br />undo<br />temp<br />temp<br />Filetransfer<br />application1<br />read-only<br />application1<br />application2<br />application2<br />deactivated<br />old server<br />New Server, Productive DB<br />system<br />system<br />undo<br />undo<br />temp<br />temp<br />application1<br />application1<br />application2<br />application2<br />impdp <metadata-file> ...<br />
    44. 44. Upgrade auf demselben Server<br />Vorbereiten neuer Datenbank und Metadaten<br />Importieren der Transportable Tablespaces<br />Kein Umkopieren notwendig<br />Aber: kein direkter Fallback möglich<br />10.2.0.4 11.2.0.2<br />create user ...<br />system<br />system<br />undo<br />undo<br />temp<br />temp<br />application1<br />application2<br />expdp transport_tablespaces=application1,...<br />impdp <metadata-file>,...<br />10.2.0.4 11.2.0.2<br />deactivated<br />system<br />system<br />undo<br />undo<br />temp<br />temp<br />application1<br />application2<br />
    45. 45. 5<br />Hardware-Migration mit Data Guard<br />Design:<br /><ul><li>Das Farbschema ist im Design als „OC 2009“ hinterlegt.
    46. 46. Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.
    47. 47. Die Standardfarben sind:</li></li></ul><li>Data Guard<br />Was ist eine Standby Database (Data Guard)?<br />Eine Standby-Datenbank (Standby) ist die Kopie einer Primärdatenbank, (Primary) die fortlaufend mit den Änderungen der Primary nachgeführt wird (synchron oder asynchron, mit oder ohne toleriertem Datenverlust).<br />Wenn die Primary ausfällt, kann die Standby "aktiviert" werden, d.h. sie übernimmt bei einem Failover die Rolle der Primary. <br />Zu Wartungszwecken kann die Rolle auch getauscht werden ("switchover").<br />Primary-DB<br />Standby-DB<br />Changes (Redo/Arc)<br />
    48. 48. Unterstützte Data Guard (DG) Konfigurationen<br />Primary/Standby auf Servern derselben Oracle Plattform<br />SQL> select platform_id, platform_name from v$database;<br />PLATFORM_ID PLATFORM_NAME<br />----------- -----------------------------------<br /> 10 Linux IA (32-bit)<br />Erlaubt sind: (MOS Note 413484.1)<br />Unterschiedlicher Hersteller (z.B. HP / IBM)<br />Unterschiedliche CPU, unterschiedliche Speichergrösse<br />Unterschiedliche OS-Distribution oder Version (RedHat/SuSE, OEL4/OEL5)<br />Innerhalb gewisser Betriebssystem-Familien<br />z.B. Linux x86 / Linux x86_64, Windows 32bit / 64bit (414043.1)<br />Zwischen verschiedenen Plattformen gleicher Endianness<br />Nur einige Kombinationen zertifiziert. z.B. (413484.1)<br />Windows 32bit  Linux 32bit<br />HPUX PA-RISC  HPUX Itanium<br />Solaris Sparc  AIX Power<br />
    49. 49. Einige Data Guard Plattform-Kombinationen(Physical Standby)<br />Kombination 32/64Bit, Neu-Kompilierung von Packages erforderlich<br />
    50. 50. Migration von 32bit Windows auf 64bit Linux<br />Aufbau eines neuen Linux Servers<br />Aufbau einer Data Guard Umgebung zwischen dem alten und neuen Server<br />Dies erfolgt ohne Downtime der Primary<br />Switchover auf neuen Server<br />Kurzer Unterbruch im Minutenbereich<br />Rekompilieren der Datenbank-Objekte<br />Abhängig von Anzahl/Performance CPU und Anzahl Packages<br />Entfernen des alten Windows Servers<br />Fallback-Szenario: Switchover auf alte Umgebung zurück<br />recompile<br />
    51. 51. 6<br />Datenbank-Upgrade mit"Rolling Migration"<br />Design:<br /><ul><li>Das Farbschema ist im Design als „OC 2009“ hinterlegt.
    52. 52. Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.
    53. 53. Die Standardfarben sind:</li></li></ul><li>Rolling Upgrade<br />Prinzip<br />Primary-Datenbank läuft wie gewohnt weiter<br />Standby-Datenbank wird in eine Logische Standby-DB (LSB) konvertiert<br />LSB ist schreibbar; nicht Block-Änderungen, sondern SQL-Statements werden appliziert<br /><ul><li>LSB hat viele Einschränkungen: nicht alle Datentypen sind unterstützt verhindert möglicherweise den Einsatz</li></ul>Log-Applizierung wird gestoppt<br />LSB wird wie eine "normale" Datenbank migriert (Primary läuft weiter)<br />Nach der Migration werden Änderungen der Primary auf LSB appliziert (sql)<br />Switchover auf die LSB  Migration auf neue Version<br />Hinweis 11g: Rolling Migration mit Physical Standby („Transient LSB“)<br />Erzeugt im Hintergrund trotzdem eine LSB, nur die DBID ändert sich dabei nichtalter databaserecovertologicalstandbykeepidentity;<br /><ul><li>Nach Flashback und CONVERT TO PHYSICAL STANDBY: REDO Apply auf alte Produktion
    54. 54. Sämtliche Limitierungen der LSB existieren weiterhin (nicht supportete Datentypen usw.)</li></li></ul><li>Rolling Migration<br />Erstellung Logical Standby<br />Physical- zu Logical-Standby konvertieren<br />Aufbau Physical Standby<br />redo-transport<br />Client<br />11.1.0.6<br />11.1.0.6<br />eth0<br />eth0<br />GuaranteedRestorepoint<br />Redo-Apply<br />Primary<br />11.1.0.6<br />Phys. Standby<br />11.1.0.6<br />Konvertierung inLogical Standby<br />Client<br />redo-transport<br />11.1.0.6<br />11.1.0.6<br />eth0<br />eth0<br />SQL-Apply<br />Primary<br />11.1.0.6<br />Logical Standby<br />11.1.0.6<br />
    55. 55. Rolling Migration<br />Migration<br />Upgrade der Logical Standby<br />Nachführen der Änderungen, die auf der (alten) Primary angefallen sind<br />X<br />redo-transport<br />Client<br />Upgrade derLogical Standby<br />11.1.0.6<br />11.1.0.6<br />11.2.0.2<br />@catupgrd.sqlCOMPATIBLE=11.1.0.6<br />eth0<br />eth0<br />Primary<br />11.1.0.6<br />logical Standby<br />11.2.0.2<br />Nachführen<br />der angefallenen<br />Änderungen<br />Client<br />redo-transport<br />11.1.0.6<br />11.2.0.2<br />eth0<br />eth0<br />SQL-Apply<br />Primary<br />11.1.0.6<br />Logical Standby<br />11.2.0.2<br />
    56. 56. Rolling Migration<br />Migration abschließen<br />Switchover auf die migrierte Logical Standby (kurze Downtime für Clients)<br />Die alte Primary kann nun auf die neue Version portiert werden<br />Switchover<br />Rollentausch<br />Prod. auf 11.2<br />Client<br />11.1.0.6<br />11.2.0.2<br />Downtime<br />eth0<br />eth0<br />Primary<br />11.1.0.6<br />Logical Standby<br />11.2.0.2<br />Client<br />redo-transport<br />flashback<br />Zum Schluss:COMPATIBLE=11.2.0.2<br />11.1.0.6<br />11.2.0.2<br />Optional: Upgrade<br />der alten Primary<br />@catupgrd.sql<br />eth0<br />eth0<br />11.2.0.2<br />Logical Standby<br />11.1.0.6<br />Primary<br />11.2.0.2<br />
    57. 57. Mixed Version (Redo Transport) Support<br /><ul><li>MOS Note 785347.1: Enterprise Edition 10.1.0.3 to 11.1.0.7
    58. 58. Streams
    59. 59. COMPATIBLE: Target ≥ Source
    60. 60. Logical Standby for Rolling Upgrade
    61. 61. Seit 10.1.0.3
    62. 62. COMPATIBLE: Target = Source
    63. 63. PhysicalData Guard
    64. 64. Target ≠ Source NOT SUPPORTED
    65. 65. NEU: 11.111.2 Rolling Upgrade via Transient Logical Standby (Script: 949322.1 und MAA=Maximum AvailabilityArchitecture Literatur)
    66. 66. Upgrade der physical Standby (Logical: CONVERT TO PHYSICAL, aus neuem Home gestartet) via Apply der Redos der neuen Primary DB</li></li></ul><li>Rolling Migration mit Plattform-Wechsel<br />Metalink 1085687.1<br />(*) nur auf Itanium, abernicht x86-64<br />
    67. 67. 7<br />Fazit<br />Design:<br /><ul><li>Das Farbschema ist im Design als „OC 2009“ hinterlegt.
    68. 68. Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.
    69. 69. Die Standardfarben sind:</li></li></ul><li>Hardware-Migration<br />Keine generelle Best Practice<br />Abhängig von Unterschieden der Plattform <br />Reduktion der Downtime<br />Kopieren der Datenbankfiles ist schneller als Export/Import der Daten<br />Keine Neu-Berechnung von Indizes<br />Ab Beginn des Kopierens muss die Datenbank gestoppt sein<br />Sonst gehen nachfolgende Änderungen verloren<br />Diese Einschränkung fällt bei Migration mit Data Guard weg<br />Es werden auch Datafiles kopiert für die Standby, aber dies geschieht bei laufender Produktion, also ohne Downtime<br />Durch Applizierung der Änderungen haben wir immer eine aktuelle Kopie, die schon bereit steht<br />
    70. 70. Datenbank-Upgrade<br />Prinzipielle Varianten<br />Upgrade der bestehenden Datenbank<br />Statt Upgrade: Datenübernahme in neuere Datenbank<br />Problem der Downtime<br />Während Upgrade-Skript (catupgrd.sql) läuft, kein Client-Zugriff<br />Lange Downtime bei vielen Objekten<br />Möglichkeiten zur Downtime-Reduktion<br />Vorherige De-Installation nicht benötigter Komponenten<br />Wird Java, XML, Oracle Text usw. wirklich verwendet? <br />Rolling Upgrade<br />Verwendung einer Logical Standby Database<br />Transportable Tablespace<br />Analog zum Beispiel der Plattform-Migration<br />Tablespaces werden an eine neuere Datenbank angehängt<br />Minimal Downtime mit zusätzlicher Replikation (GoldenGate, Shareplex, …)<br />
    71. 71. Datenbank-Upgrade<br />Tipps<br />Upgrade Advisors<br />Oracle Support Upgrade Advisors [ID 250.1]mitvielenVerweisen auf weitereDokumente<br />Database Upgrade from 9.2 to 11.2 [264.1]<br />Database Upgrade from 10.2 to 11.2 [251.1]<br />TTS – Transportable Tablespaces<br />Master Note for Transportable Tablespaces (TTS) -- Common QuestionsandIssues [ID 1166564.1]<br />10g : Transportable Tablespaces Across Different Platforms [ID 243304.1]<br />What Objects Are Exported With Transportable Tablespaces (TTS)? [ID 883153.1]<br />Data Guard Physical Standby<br />Master Note for Data Guard [ID 1101938.1]<br />Data Guard Logical Standby<br />Mixed Oracle Version support with Data Guard Redo Transport Services [ID 785347.1]<br />Data Guard Support for Heterogeneous Primary and Logical Standbys in Same Data Guard Configuration [ID 1085687.1]<br />Troubleshooting Logical Standby [ID 215020.1]<br />MAA – Oracle Maximum AvailabilityArchitecture<br />http://www.oracle.com/technetwork/database/features/availability/index.html<br />
    72. 72. Fragen und Antworten<br />
    73. 73. Kontakt<br /><ul><li>Christian Ballweg, Senior Consultant</li></ul> OPITZ CONSULTING Essen GmbHchristian.ballweg@opitz-consulting.comTelefon +49 201 89 29 94 - 1718Mobil +49 173 8978636<br />

    ×