Eine Datenbank im Quantensprung

Transkript

2 Quest Software Simplicity at Work Quest unterstützt Unternehmen dabei, das IT-Management zu vereinfachen und Kosten zu reduzieren. Die Produktivität von DBAs and Entwicklern verbessern und die Datenbank-Performance erhöhen

3 Herrmann & Lenz Services GmbH Herrmann & Lenz Solutions GmbH Erfolgreich seit 1996 am Markt Firmensitz: Burscheid (bei Leverkusen) Beratung, Schulung und Betrieb/Fernwartung rund um das Thema Oracle Datenbanken Schwerpunktthemen: Hochverfügbarkeit, Tuning, Migrationen und Troubleshooting Herrmann & Lenz Solutions GmbH Produkt: Monitoring Module Stand auf Ebene 2

4 Agenda Kurze Vorstellung Agenda Projektrahmen Danke! nein Migrationsmethoden Einige Vorbereitung Der Quantensprung Fragen? ja Antwort Fazit

5 Wie kam das alles? Komplexe, weltweit genutzte Datenbank Konfigurationen/Beschreibungen/Historie jedes ausgelieferten Produkts Auszeiten? Wenige Stunden, Mitte Ostern oder Weihnachten Ausgangszustand: Datenbank auf HP-UX 7TB groß, GB Redolog pro Tag WE8ISO8859P1 als Standardzeichensatz NCHAR-Datentypen als Workaround für asiatische/arabische Zeichen Dutzende Schnittstellen und angrenzende Systeme Diverse Performance-Probleme mit der Hauptanwendung (Oracle BEA Weblogic) Ursache laut Oracle im Zusammenspiel Weblogic / NCHARs Von Oracle vorgeschlagene Lösung: Datenbank bitte auf Unicode als Standardzeichensatz migrieren!

6 Projektrahmen Kaum Auszeiten EINE All-in-One-Migration Beibehaltung der Oracle-Version Umstellung auf Unicode als Standardzeichensatz (AL32UTF8) Typkonvertierung der Tabellenspalten NCHAR CHAR, NVARCHAR2 VARCHAR2, NCLOB CLOB (mehrere TB Dokumente) HP-UX PA-RISC / Big Endian Linux x86_64 / Little Endian Beseitigung bestehender Kapazitätsengpässe Unternehmensweite Kooperation mit Intel Migration auf neues Storage Partitionierung einiger großer Tabellen Weitere Rahmenbedingungen Vor der Umstellung: realistische Testläufe auf der neuen Datenbank Bis zu 2 Wochen nach der Umstellung muss Fallback auf die alte Datenbank möglich sein, ohne Datenverlust

7 Upgrade- und Migrationsmethoden Methode Version Storage Zeichen satz Reorg. Auszeit Plattform In- Place Fallback v/n Komplexität Standard- Upgrade Export / Import Transportable Tablespace Transportable Database ASM Rebalancing Rolling Upgrade Rolling Migration X O kurz X X/O gering X X X X X sehr lang X/X gering X X lang X/X mittel O X lang X/X gering X keine X/X gering X O X sehr kurz X/X hoch X X X X X sehr kurz X/X hoch

8 Upgrade- und Migrationsmethoden Methode Version Storage Zeichen satz Reorg. Auszeit Plattform In- Place Fallback v/n Komplexität Standard- Upgrade Export / Import Transportable Tablespace Transportable Database ASM Rebalancing Rolling Upgrade Rolling Migration X O kurz X X/O gering X X X X X sehr lang X/X gering X X lang X/X mittel O X lang X/X gering X keine X/X gering X O X sehr kurz X/X hoch X X X X X sehr kurz X/X hoch

9 Upgrade- und Migrationsmethoden Methode Version Storage Zeichen satz Reorg. Auszeit Plattform In- Place Fallback v/n Komplexität Standard- Upgrade Export / Import Transportable Tablespace Transportable Database ASM Rebalancing Rolling Upgrade Rolling Migration X O kurz X X/O gering X X X X X sehr lang X/X gering X X lang X/X mittel 7TB und viele LOBs: Ca. 1 Woche O X lang X/X gering X keine X/X gering X O X sehr kurz X/X hoch X X X X X sehr kurz X/X hoch

10 Upgrade- und Migrationsmethoden Methode Version Storage Zeichen satz Reorg. Auszeit Plattform In- Place Fallback v/n Komplexität Standard- Upgrade Export / Import Transportable Tablespace Transportable Database ASM Rebalancing Rolling Upgrade Rolling Migration X O kurz X X/O gering X X X X X sehr lang X/X gering X X lang X/X mittel 7TB und viele LOBs: Ca. 1 Woche Fallback ohne Datenverlust: Ca. 1 Woche O X lang X/X gering X keine X/X gering X O X sehr kurz X/X hoch X X X X X sehr kurz X/X hoch

11 SharePlex Schritt 1 Zeit Changes Alt-DB 12:00 Uhr (SCN 1000) Start der Replikation Neu-DB (leer) Laufende Änderungen werden repliziert und gepuffert

12 SharePlex Schritt 2 (Variante A) Zeit Changes Alt-DB 12:00 Uhr (SCN 1000) Start der Replikation Ein bisschen später, z.b. 12:05 Uhr (SCN 1100) exp flashback_scn=1100 expdp flashback_scn=1100 Neu-DB (Snapshot 12:05)

13 SharePlex Schritt 2 (Variante A) Zeit Changes Alt-DB 12:00 Uhr (SCN 1000) Start der Replikation Ein bisschen später, z.b. 12:05 Uhr (SCN 1100) exp flashback_scn=1100 expdp flashback_scn=1100 Neu-DB (Snapshot 12:05) Hätte extrem viel Undo-Retention / Undo- Tablespace erfordert

14 SharePlex Schritt 2 (Variante B) Zeit Changes Alt-DB 12:00 Uhr (SCN 1000) Start der Replikation Ein bisschen später, z.b. 12:05 Uhr (SCN 1100) Neu-DB (Snapshot 12:05) Standby-DB bis SCN 1100 recovern, dann öffnen Datapump Export/Import + HLTablePump (Turbo-Booster für LOBs) Alt-DB Standby

15 Import bei Zeichensatzwechsel Oracle Import liefert viele Fehlermeldungen der Art:. Import der Tabelle "STATUS" IMP-00019: Zeile zurückgewiesen aufgrund von Oracle-Fehler IMP-00003: ORACLE-Fehler aufgetreten ORA-12899: Wert zu groß für Spalte DEMO"."STATUS"."STATUSID" (aktuell: 2, maximal: 1) Spalte 1 Ü Spalte 2 ÜBERTRAG Spalte 3 Umlauttest Ursache: Längensemantik für CHAR / VARCHAR2-Spalten VARCHAR2(50) meint per Default 50 Byte, nicht 50 Zeichen Bei Unicode braucht man stattdessen: VARCHAR2(50 CHAR)

16 Längensemantik umstellen Auf der Quell-Datenbank: Für alle Tabellen Create-Skript OHNE Längensemantik erstellen DBMS_METADATA: Lässt die Längensemantik standardmäßig weg Toad: Menüpunkt Generate Schema Script Zuvor in den Optionen ein Häkchen rausnehmen SPOOL create_tables.sql SELECT DBMS_METADATA.get_ddl ( 'TABLE', table_name, owner) ';' FROM dba_tables WHERE owner IN (<benutzerliste>); SPOOL OFF

17 Längensemantik umstellen Auf der Ziel-Datenbank: Längensemantik manuell umsetzen ALTER SESSION SET NLS_LENGTH_SEMANTICS = 'CHAR' Ausführen des zuvor erstellten Create-Skripts CREATE TABLE demo.personen ( persid NUMBER(10), anrede VARCHAR2(5), vorname VARCHAR2(50), nachname VARCHAR2(50), geburtstag DATE, bild BLOB); Dann Import bzw. Data Pump-Import Imp IGNORE=Y Impdp TABLE_EXISTS_ACTION=APPEND

18 Noch ein paar Herausforderungen Weitere Anpassungen der Create-Skripte für Tabellen Partitionierung einiger großer Tabellen Konvertierung der Tabellenspalten NCHAR CHAR, NVARCHAR VARCHAR2, NCLOB CLOB Search / Replace in den generierten Create-Skripten IMP-00058: ORACLE-Fehler aufgetreten ORA-24806: LOB-Form stimmt nicht überein Exp/imp kann nicht NCLOB CLOB konvertieren Mit Data Pump geht es aber SharePlex-Replikation konnte das auch nicht, Patch geliefert

19 und die Data-Pump-Performance bei LOBs Größtes LOB-Segment hatte > 2 TB DP-Export abgebrochen bei 50% der Datenmenge nach fünf Tagen (!) Data-Pump-Parallelisierung nicht möglich wegen Bugs beim DP-Import NETWORK_LINK-Benutzung ebenfalls nicht möglich unterstützt keine Typkonvertierung CLOB NCLOB Lösung: Eigene Entwicklung HLTablePump Parallelisierung über Wertebereiche Innerhalb der parallelen Tasks Multi-Threaded-Verarbeitung Direktes Einfügen der gelesenen Daten in die Ziel-DB ohne Zwischenspeicherung Laufzeit für die komplette Datenmenge: 23 Stunden

20 SharePlex Schritt 2 (Variante B) Zeit Changes Alt-DB 12:00 Uhr (SCN 1000) Start der Replikation Ein bisschen später, z.b. 12:05 Uhr (SCN 1100) Neu-DB (Snapshot 12:05) Standby-DB bis SCN 1100 recovern, dann öffnen Datapump Export/Import + HLTablePump (Turbo-Booster für LOBs) Alt-DB Standby

21 SharePlex Schritt 3 Zeit Changes Alt-DB Änderungen zwischen 12:00 und 12:05 werden verworfen. Der Rest wird repliziert. Neu-DB (Replikat) Trigger und Datenbankjobs müssen vorerst disabled werden!

22 SharePlex Geschafft Alt-DB Asynchrone Replikation, typischerweise wenige Sekunden Nachlauf Neu-DB (Replikat)

23 Anwendungstests Vorbereiten: Einschalten von Flashback auf der neuen DB SQL> ALTER SYSTEM SET db_flashback_retention_target=<dauer in minuten>; SQL> ALTER DATABASE ARCHIVELOG; SQL> ALTER DATABASE FLASHBACK ON; SQL> ALTER DATABASE OPEN; Replikation aussetzen Änderungen werden gepuffert Oracle Restore Point erstellen SQL> CREATE RESTORE POINT vor_test [GUARANTEE FLASHBACK DATABASE]; Tests durchführen (beliebige Abfragen und Änderungen) Zurücksetzen der Datenbank auf den Restore Point SQL> FLASHBACK DATABASE TO RESTORE POINT vor_test; Replikation wieder aufnehmen und nachfahren

24 SharePlex Der Quantensprung Alt-DB - Benutzer abmelden - Anwendungen und sonstige Schnittstellen stoppen - ggf. IP-Adressen / Hostnamen tauschen etc. Neu-DB (Replikat) Trigger und Datenbankjobs müssen jetzt wieder enabled werden!

25 SharePlex Migration abgeschlossen Alt-DB (Replikat) Fallback der Anwendung jederzeit möglich (für 2 Wochen laufen gelassen) Neu-DB (produktiv) - Benutzer / Anwendungen gegen neue Datenbank starten

26 Projektergebnis Erster Anlauf: physische und logische Datenfehler in der bestehenden Datenbank entdeckt Zweiter Anlauf sah sehr gut aus Problem mit dem Storage der neuen Datenbank Corruptions Dritter Anlauf: Umschaltung am Ostermontag Nach mehreren Testläufen mittels Flashback Database Gesamte Auszeit ca. 4 Stunden Aus Service- / Anwendungssicht, nicht Datenbanksicht! Für die meisten Länder keine spürbare Auszeit, insb. USA and China Unmittelbare Performance-Verbesserung gespürt Seitdem deutlich weniger Probleme mit der Anwendung Zwei Wochen später: Fallback-Replikation abgeschaltet

27 Fazit Die konkreten Rahmenbedingungen bestimmen die beste Migrationsmethode Trade-Off zwischen Auszeit und Risiko einerseits Komplexität und Umsetzungsaufwand andererseits Sehr komplexe und dennoch sichere Umstellungen in einem Schritt sind möglich Funktionale und Performance-Testläufe geben Sicherheit Enterprise Edition: Flashback Database, Rolling Upgrade/Migration Ansonsten: Backups Geschäftskritische Datenbanken migrieren ist ein Projekt Auch bei genauer Planung passieren unvorhergesehene Dinge Erste Bestandsaufnahme: Juli 2009; Abschluss: 20. April 2010