Successfully reported this slideshow.
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.744 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
  • Als Erste(r) kommentieren

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 />

×