ORACLE Database Migration

Transkript

1 ORACLE Database Migration Hürden und Best Practices in einer hochverfügbaren Umgebung GUUG FFG 2013 Andrea Held :47:05 A. Held: Oracle DB Migration 1

2 Agenda Oracle Hochverfügbarkeit: Eine Auswahl Migrationspfade Das Projekt :47:05 A. Held: Oracle DB Migration Seite 2

3 Hochverfügbarkeit mit Oracle eine Auswahl :17:16 A. Held: Oracle DB Migration 4

4 Oracle Real Application Clusters (RAC) - Arbeit im Team :17:17 A. Held: Oracle DB Migration Seite 5

5 Oracle RAC Eine Datenbank mehrere Instanzen Vorgänger Oracle Parallel Server Global Cache Aktiv/Aktiv-Konfiguration mit Shared Storage Verteiltes Sperrmanagement Client 1 Client 2 Client 3 Client 4 Client 5 Client 6 Client 7 Client 8 Client 9 Client 10 Client 11 Client n N etzw erk Clu ster In terco nn ect (redundant ausgelegt)... Oracle Instance auf No de 1 Oracle Instance auf No de :17:25 A. Held: Oracle DB Migration O racle Datenb ank auf Shared Disk Su bsystem Seite 6

6 Oracle RAC :17:25 A. Held: Oracle DB Migration Seite 7

7 Oracle RAC Voraussetzungen: Shared Storage Private Network / Cluster Interconnect Public Network :17:25 A. Held: Oracle DB Migration 8

8 Oracle RAC Pro: Extrem kurze Failover-Zeiten Mit Standard Edition realisierbar Ab 10g/11g 4 Prozessoren insgesamt (4x1 oder 2x2 CPU-Cluster) Nur mit ASM und Oracle ClusterReadyServices 10:44:17 A. Held: Oracle DB Migration Seite 9

9 Oracle RAC Pro: Extrem kurze Failover-Zeiten Mit Standard Edition realisierbar Contra: Nur bei 10g/11g 4 Prozessoren insgesamt (4x1 oder 2x2 CPU-Cluster) Nur mit ASM und Oracle ClusterReadyServices Skaliert nicht mit jeder Anwendung optimal Ausfall der DB nicht abgesichert Nicht jede Distanz beliebig realisierbar Seite 10 10:44:19 A. Held: Oracle DB Migration

10 Der Klon unter den Datenbanken: Data Guard 10:44:20 A. Held: Oracle DB Migration Seite 11

11 Oracle Data Guard Standby-Datenbank 10:44:23 A. Held: Oracle DB Migration Seite 12

12 Oracle Data Guard Typen: Physical Active Logical 10:44:23 A. Held: Oracle DB Migration 13

13 Oracle Data Guard Physical Standby 1:1 Kopie des Originals Switchover (Rollentausch) Erlaubt Rolling Upgrades Kurze Downtime für Rollenwechsel nötig Failover (Übernahme bei Ausfall Observer für automatisierten Failover nutzbar Failoverzeiten < 2 Minuten realisierbar Mit Active Data Guard: read only Zugriff auf Standby möglich 10:44:23 A. Held: Oracle DB Migration Seite 14

14 Oracle Data Guard Logical Standby Nicht mit Primär-Datenbank identisch / nur logische Kopie SQL Apply Es können Struktur-Unterschiede implementiert werden: Zusätzliche Indizes Zusätzliche Materialized Views etc. Kann für Reporting-Zwecke geöffnet und gelesen werden. Seite 15

15 Oracle Data Guard Pro Einfach zu installieren Über große Distanzen realisierbar Deckt gleich mehrere Szenarien ab: Rechner Ausfall Storage Ausfall RZ Ausfall Seite 16

16 Oracle Data Guard Pro Einfach zu installieren Über große Distanzen realisierbar Deckt gleich mehrere Szenarien ab: Rechner Ausfall Storage Ausfall RZ Ausfall Contra Lizenzkosten 17

17 Zurück in die Zukunft: Oracle Flashback Seite 18

18 Zurück in die Zukunft: Oracle Flashback Flashback Query: Einzelner Satz Flashback Versions Query: Satzversionen Flashback Transaction Query: Komplette Transaction Flashback Transaction: Transaktion rückgängig Flashback Table: Datenbestand zurücksetzen Flashback Drop: Tabelle wiederherstellen Flashback Database: Komplette Datenbank zurücksetzen Flashback Data Archive (auch Total Recall): Archivierung Seite 19

19 Flashback Database DB muss im Archivelog Mode betrieben werden.s Muss zuvor mit ALTER DATABASE FLASHBACK ON aktiviert worden sein. Größe des Flash Recovery Area sowie der DB Parameter db_flashback_retention_target bestimmen, wie weit zurückgesetzt werden kann. Seite 20

20 Flashback Database -- Datenbank in Mount-Mode shutdown immediate; startup mount; -- Flashback der Datenbank FLASHBACK DATABASE TO TIMESTAMP to_timestamp (' :30:00','dd.mm.yyyy hh24:mi:ss'); -- Datenbank mit open resetlogs öffnen alter database open resetlogs; Seite 21

21 Flashback Database Pro Einfache Anwendung Sehr flexibel Mit Restore Points nutzbar Geeignet für Lasttests Seite 22

22 Flashback Database Pro Einfache Anwendung Sehr flexibel Mit Restore Points nutzbar Geeignet für Lasttests Contra Lizenzkosten Seite 23

23 Migrationspfade 24

24 Migrationspfade Duplicate Database, Cloning Transportable Tablespaces Export / Import, Data Pump Oracle Streams / Golden Gate / Replikation Seite 25

25 Duplicate Database Kopie der Datenbank Benötigte Zeit abhängig von DB-Größe 26

26 Transportable Tablespace müssen self containing sein Können durch Kopie oder auch durch umhängen des Storage verwendet werden Plattformwechsel möglich Limitierung: Zeichensatzwechsel Seite 27

27 Data Pump Export und Import über Files Import direkt über Database Link Zieldatenbank kann abweichen im Hinblick auf: Plattform Oracle Release Zeichensatz Architektur Seite 28

28 Data Pump Export und Import über Files Import direkt über Database Link Zieldatenbank kann abweichen im Hinblick auf: Plattform: Solaris => Linux Oracle Release: 11.1 => 11.2 Zeichensatz: WE8ISO8859P1 => UTF8 Architektur: RAC => Data Guard Seite 29

29 Downtime minimieren Golden Gate Oracle Streams Oracle Physical Standby Oracle Logical Standby Tools von Dritt-Anbietern wie Quest Shareplex 30

30 Das Projekt Seite 31

31 Ausgangssituation Oracle Real Application Clusters (RAC) Oracle Database Zeichensatz WE8ISO8859P1 Sun Solaris Ziel Wechsel von RAC auf Oracle Data Guard Wechsel von Oracle Database auf Zeichensatzwechsel von UTF8 Wechsel von Solaris auf Suse SLES Seite 32

32 Alternative Migrationspfade Seite 33

33 Alternative Migrationspfade Duplicate Database, Cloning: Upgrade und Zeichensatzwechsel zusätzlich erforderlich Seite 34

34 Alternative Migrationspfade Duplicate Database, Cloning: Upgrade und Zeichensatzwechsel zusätzlich erforderlich Physical Standby: unterstützt 11.1 auf 11.2, aber nicht den Plattformwechsel, Zeichensatzwechsel zusätzlich erforderlich Seite 35

35 Alternative Migrationspfade Duplicate Database, Cloning: Upgrade und Zeichensatzwechsel zusätzlich erforderlich Physical Standby: unterstützt 11.1 auf 11.2, aber nicht den Plattformwechsel, Zeichensatzwechsel zusätzlich erforderlich Transportable Tablespaces: Unterstützt Plattformwechsel, aber nicht den Zeichensatzwechsel Seite 36

36 Alternative Migrationspfade Duplicate Database, Cloning: Upgrade und Zeichensatzwechsel zusätzlich erforderlich Physical Standby: unterstützt 11.1 auf 11.2, aber nicht den Plattformwechsel, Zeichensatzwechsel zusätzlich erforderlich Transportable Tablespaces: Unterstützt Plattformwechsel, aber nicht den Zeichensatzwechsel Oracle Streams, Golden Gate etc.: Primärsystem muss angefasst werden Seite 37

37 Migrationspfad Installation des neues Systems mit Oracle Data Guard 11.2 auf Linux mit neuem Zeichensatz Übernahme der Daten mit Data Pump Über Datenbank Link Reduktion des Wartungsfenster durch Trennung der Schemata Seite 38

38 Migrationspfad Trennung der Schemata in Stammdaten Bewegungsdaten Archiv Seite 39

39 Migrationspfad Trennung der Schemata in Stammdaten: Vor Wartungsfenster Bewegungsdaten: Im Wartungsfenster Archiv: Nach dem Wartungsfenster Seite 40

40 Ablauf Neue und leere DB erstellen Auf neuer Plattform mit neuen Oracle Release und neuem Zeichensatz Seite 41

41 Ablauf Neue und leere DB erstellen Schema implementieren Wichtig: Längensemantik auf Char setzen Wegen partionierter Tabellen muss dies gleich bei der Tabellenerstellung geschehen Mit Data Pump SQL extrahieren, über Shell Scripting byte in char umsetzen, SQL File mit Datenmodell in Ziel-DB implementieren Seite 42

42 Ablauf Neue und leere DB erstellen Schema implementieren Trigger und Constraints deaktivieren Seite 43

43 Ablauf Neue und leere DB erstellen Schema implementieren Trigger und Constraints deaktivieren Stammdaten importieren (ohne Wartungsfenster) Seite 44

44 Ablauf Neue und leere DB erstellen Schema implementieren Trigger und Constraints deaktivieren Stammdaten importieren (ohne Wartungsfenster) Bewegungsdaten importieren (Wartungsfenster) Seite 45

45 Ablauf Neue und leere DB erstellen Schema implementieren Trigger und Constraints deaktivieren Stammdaten importieren (ohne Wartungsfenster) Bewegungsdaten importieren (Wartungsfenster) Trigger und Constraints aktivieren (Wartungsfenster) Seite 46

46 Ablauf Neue und leere DB erstellen Schema implementieren Trigger und Constraints deaktivieren Stammdaten importieren (ohne Wartungsfenster) Bewegungsdaten importieren (Wartungsfenster) Trigger und Constraints aktivieren (Wartungsfenster) Archiv importieren (ohne Wartungsfenster) Seite 47

47 Ergebnis Wechsel aller geforderten Parameter Wartungsfenster reduziert Seite 48

48 Downtime minimieren Konfiguration: Quelle: Oracle auf Solaris mit WE8ISO8859P1 Ziel: Oracle 11.2.x auf Linux mit UTF8 Zunächst das Schema mit Dateninhalten aufbauen Änderung der Längensemantik für Datentypen von Byte auf Char Erstellen des Ziel-Schemas Exportieren der Daten auf der Quelle Import der Daten auf dem Ziel Synchronisation zwischen Quelle und Ziel bspw. mit SharePlex Optional: Tests der Anwendung mit Flashback-Technologie Umschalten der Anwendung 49

49 Hürden DB Link nicht mit Parameter parallel nutzbar Übernahme des Datenmodells Bei Zeichensatzwechsel: Änderung der Längensemantic von Byte auf Char Probleme bei partitionierten Tabellen 13 Bugs während der Migration entdeckt Seite 50

50 Hürden 51

51 Resümee Komplexität reduzieren Trennung der Schemata => Kosten Cloning ist wesentlich unkomplizierter Zur Downtime-Reduzierung: Replikationsverfahren erforderlich Seite 52

52 Fragen und Antworten Kontakt: Xing, Facebook, LinkedIn, Skype oder Seite 53