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.

1. Oracle Datenbank-Migration Düsseldorf, 17. März 2011 Oracle 11gR2 Erfahrungen Christian BallwegSenior ConsultantOPITZ CONSULTING Essen GmbH

3. Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.

5. Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.

7. Migrationsvarianten Was wollen wir migrieren? Lösungswege? Versions-Upgrade ja nein HardwareAustausch HardwareAustausch ja ja nein nein Plattform-Austausch Plattform-Austausch catupgrd.sql fertig  ja nein ja nein Endian-Wechsel nein ja ... ... ... 11g ... DataGuard

9. Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.

11. Plattform-unabhängig

12. Langsam (kein direct-path-load, keine Parallelisierung)

14. Erst ab Oracle 10g verfügbar

16. Generell: keine (eigenen) Objekte unter SYS!Export Import

18. Parallelisierbar

19. Nur Datenübernahme, Scripts für Erstellung und Transfer selbst zu implementierenDatabase-Link create table as select ... Etwa gleiche Vor- und Nachteile wie bei sqlplus/sqlldr

23. Neu aufgebaute, reorganisierte Datenbank, Nutzung aller neuen Features möglich

26. Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.

28. Risikoarm, da keine Änderung an der Datenbank

29. Downtime für die Zeit des Kopierens

30. Nur innerhalb der gleichen Plattform

31. Kein Upgrade der Oracle Version

32. Keine Reorganisation der Daten/Indizescopy

34. Gewisse Plattform-Migrationen sind möglich

35. Nur für Plattformen desselben Endian-Formats

36. Erst ab Oracle 10g

38. Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.

40. Datenbank-Upgrade möglich

43. Migration/Upgrade mit Transportable Tablespace Transferieren der Tablespaces (mit Metadaten) Importieren der transportierten Tablespaces Gegebenenfalls vorher rman convert datafile expdp transport_tablespaces=application1,... Old Server New Server, Empty Database system system undo undo temp temp Filetransfer application1 read-only application1 application2 application2 deactivated old server New Server, Productive DB system system undo undo temp temp application1 application1 application2 application2 impdp <metadata-file> ...

44. Upgrade auf demselben Server Vorbereiten neuer Datenbank und Metadaten Importieren der Transportable Tablespaces Kein Umkopieren notwendig Aber: kein direkter Fallback möglich 10.2.0.4 11.2.0.2 create user ... system system undo undo temp temp application1 application2 expdp transport_tablespaces=application1,... impdp <metadata-file>,... 10.2.0.4 11.2.0.2 deactivated system system undo undo temp temp application1 application2

46. Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.

48. Unterstützte Data Guard (DG) Konfigurationen Primary/Standby auf Servern derselben Oracle Plattform SQL> select platform_id, platform_name from v$database; PLATFORM_ID PLATFORM_NAME ----------- ----------------------------------- 10 Linux IA (32-bit) Erlaubt sind: (MOS Note 413484.1) Unterschiedlicher Hersteller (z.B. HP / IBM) Unterschiedliche CPU, unterschiedliche Speichergrösse Unterschiedliche OS-Distribution oder Version (RedHat/SuSE, OEL4/OEL5) Innerhalb gewisser Betriebssystem-Familien z.B. Linux x86 / Linux x86_64, Windows 32bit / 64bit (414043.1) Zwischen verschiedenen Plattformen gleicher Endianness Nur einige Kombinationen zertifiziert. z.B. (413484.1) Windows 32bit  Linux 32bit HPUX PA-RISC  HPUX Itanium Solaris Sparc  AIX Power

49. Einige Data Guard Plattform-Kombinationen(Physical Standby) Kombination 32/64Bit, Neu-Kompilierung von Packages erforderlich

50. Migration von 32bit Windows auf 64bit Linux Aufbau eines neuen Linux Servers Aufbau einer Data Guard Umgebung zwischen dem alten und neuen Server Dies erfolgt ohne Downtime der Primary Switchover auf neuen Server Kurzer Unterbruch im Minutenbereich Rekompilieren der Datenbank-Objekte Abhängig von Anzahl/Performance CPU und Anzahl Packages Entfernen des alten Windows Servers Fallback-Szenario: Switchover auf alte Umgebung zurück recompile

52. Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.

55. Rolling Migration Migration Upgrade der Logical Standby Nachführen der Änderungen, die auf der (alten) Primary angefallen sind X redo-transport Client Upgrade derLogical Standby 11.1.0.6 11.1.0.6 11.2.0.2 @catupgrd.sqlCOMPATIBLE=11.1.0.6 eth0 eth0 Primary 11.1.0.6 logical Standby 11.2.0.2 Nachführen der angefallenen Änderungen Client redo-transport 11.1.0.6 11.2.0.2 eth0 eth0 SQL-Apply Primary 11.1.0.6 Logical Standby 11.2.0.2

56. Rolling Migration Migration abschließen Switchover auf die migrierte Logical Standby (kurze Downtime für Clients) Die alte Primary kann nun auf die neue Version portiert werden Switchover Rollentausch Prod. auf 11.2 Client 11.1.0.6 11.2.0.2 Downtime eth0 eth0 Primary 11.1.0.6 Logical Standby 11.2.0.2 Client redo-transport flashback Zum Schluss:COMPATIBLE=11.2.0.2 11.1.0.6 11.2.0.2 Optional: Upgrade der alten Primary @catupgrd.sql eth0 eth0 11.2.0.2 Logical Standby 11.1.0.6 Primary 11.2.0.2

58. Streams

59. COMPATIBLE: Target ≥ Source

60. Logical Standby for Rolling Upgrade

61. Seit 10.1.0.3

62. COMPATIBLE: Target = Source

63. PhysicalData Guard

64. Target ≠ Source NOT SUPPORTED

65. NEU: 11.111.2 Rolling Upgrade via Transient Logical Standby (Script: 949322.1 und MAA=Maximum AvailabilityArchitecture Literatur)

68. Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.

70. Datenbank-Upgrade Prinzipielle Varianten Upgrade der bestehenden Datenbank Statt Upgrade: Datenübernahme in neuere Datenbank Problem der Downtime Während Upgrade-Skript (catupgrd.sql) läuft, kein Client-Zugriff Lange Downtime bei vielen Objekten Möglichkeiten zur Downtime-Reduktion Vorherige De-Installation nicht benötigter Komponenten Wird Java, XML, Oracle Text usw. wirklich verwendet? Rolling Upgrade Verwendung einer Logical Standby Database Transportable Tablespace Analog zum Beispiel der Plattform-Migration Tablespaces werden an eine neuere Datenbank angehängt Minimal Downtime mit zusätzlicher Replikation (GoldenGate, Shareplex, …)

71. Datenbank-Upgrade Tipps Upgrade Advisors Oracle Support Upgrade Advisors [ID 250.1]mitvielenVerweisen auf weitereDokumente Database Upgrade from 9.2 to 11.2 [264.1] Database Upgrade from 10.2 to 11.2 [251.1] TTS – Transportable Tablespaces Master Note for Transportable Tablespaces (TTS) -- Common QuestionsandIssues [ID 1166564.1] 10g : Transportable Tablespaces Across Different Platforms [ID 243304.1] What Objects Are Exported With Transportable Tablespaces (TTS)? [ID 883153.1] Data Guard Physical Standby Master Note for Data Guard [ID 1101938.1] Data Guard Logical Standby Mixed Oracle Version support with Data Guard Redo Transport Services [ID 785347.1] Data Guard Support for Heterogeneous Primary and Logical Standbys in Same Data Guard Configuration [ID 1085687.1] Troubleshooting Logical Standby [ID 215020.1] MAA – Oracle Maximum AvailabilityArchitecture http://www.oracle.com/technetwork/database/features/availability/index.html

72. Fragen und Antworten