Daten von Oracle® nach Cloud SQL for MySQL migrieren

Dieses Dokument ist Teil einer Reihe, in der Ihnen gezeigt wird, wie Sie Daten von Oracle nach Cloud SQL for MySQL migrieren. Die folgenden Dokumente der Reihe bieten ausführlichere Informationen:

Vorbereitung der Datenmigration

In diesem Abschnitt wird beschrieben, wie Sie Daten von Oracle zu Cloud SQL for MySQL migrieren. Die folgenden Voraussetzungen sind entscheidend, um Probleme während der Live-Migration zu vermeiden:

  • Die Schema-Umwandlung von Oracle zu Cloud SQL for MySQL wurde für alle Datenbankobjekte ausgeführt, einschließlich Tabellen, Ansichten, gespeicherter Prozeduren und Funktionen.
  • Das Zielschema wurde mit einigen Beispieldaten getestet, um zu prüfen, ob es dieselben Daten wie das Quellschema enthalten kann.

Es gibt zwei grundlegende Methoden für die Datenmigration: einmaliges Laden und Echtzeitreplikation. Beim einmaligen Laden werden die vorhandenen Daten aus Oracle exportiert und in MySQL importiert. Bei der Replikationsmethode in Echtzeit werden Daten während der Generierung von Oracle nach MySQL sofort kopiert.

Bei der einmaligen Lademethode darf die Quelldatenbank während des Vorgangs nur für Schreibvorgänge geöffnet sein. Diese Methode wird auch als Offline-Datenmigration bezeichnet. Eines der beliebtesten Tools zum Exportieren von Daten aus Oracle ist Oracle SQL Developer. Mit diesem Tool können Sie Daten aus Oracle-Tabellen in zahlreichen Formaten exportieren, darunter CSV- und SQL-Einfügeanweisungen. Alternativ können Sie mit SQL*Plus Ihre Daten auswählen, formatieren und in eine Datei verschieben. Nachdem die Daten von Oracle in eine Flat-Datei exportiert wurden, können Sie sie mit dem Befehl LOAD DATA INFILE in MySQL laden. Diese Methode ist häufig die günstigste Migrationsmethode, sie kann jedoch mehr manuelle Eingaben beinhalten und langsamer als ein Migrationstool sein. Das erfordert auch Ausfallzeiten für die Anwendung.

Im Gegensatz dazu ist die Replikationsmethode in Echtzeit, auch als Änderungserfassung bezeichnet, eine Methode zur Onlinedatenmigration. Während der ersten Datenkopie bleibt die Quelldatenbank geöffnet. Ein Replikationsprodukt erfasst Datenänderungen, die in der Quelldatenbank auftreten, und nutzt diese, um die Änderungen auf die Zieldatenbank anzuwenden. Bei Produktionsmigrationen können Sie diese Methode verwenden, um die erforderliche Ausfallzeit zu minimieren und eine Ausfallzeit von fast null zu gewährleisten, bevor der Umstellungsprozess stattfindet. Diese Methode umfasst die Verwendung eines CDC-Produkts (Change of Capture) von Drittanbietern wie GoldenGate, Striim oder Datenreplikation von Informatica.

Um CDC von Oracle als Quelldatenbank zuzulassen, empfehlen wir Ihnen, das zusätzliche Logging auf Datenbankebene mit folgendem Befehl zu aktivieren:

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

Database altered.

Dieser Befehl bewirkt, dass die Redo-Logdateien zusätzlich zu den üblichen Primärschlüsseln oder eindeutigen Indexspalten weitere Spaltendaten erfassen.

Sie können das CDC-Produkt eines Drittanbieters für sowohl den anfänglichen Ladeschritt – alle vorhandenen Daten (bis zu mehreren TB an Daten) aus der Quell-Oracle-Datenbankumgebung übertragen – als auch zum Erfassen laufender Datenänderungen, bis beide Umgebungen synchronisiert sind, bevor der Wechsel zwischen den beiden Plattformen durchgeführt wird. Ein CDC-Produkt bietet in der Regel zusätzliche Features wie Datentyp-Konvertierungen und andere einfache Transformationen.

Datenmigration ausführen

Folgen Sie bei der Migration der Daten die folgenden Richtlinien, von denen die meisten sowohl die einmalige Lademethode als auch die Echtzeit-Replikation betreffen:

  • Zeichensätze: Sorgen Sie für kompatible Zeichensätze zwischen der Quell-Oracle-Datenbank und der MySQL-Zieldatenbank.
  • Fremdschlüssel: Um die Aufnahme zu beschleunigen, deaktivieren Sie vorübergehende Schlüsseleinschränkungen für die MySQL-Zieldatenbank. Wenn der Ladevorgang abgeschlossen ist, aktivieren Sie die Einschränkungen für Fremdschlüssel.
  • Indexe: Ähnlich wie Fremdschlüssel können Indexe in der MySQL-Zieldatenbank die anfängliche Last erheblich verlangsamen. Achten Sie darauf, dass Indexe erst in der Zieldatenbank erstellt werden, wenn der anfängliche Ladevorgang abgeschlossen ist.
  • Oracle-Sequenzen: MySQL unterstützt AUTO_INCREMENT anstelle von Sequenzen. Die AUTO_INCREMENT-Attribute müssen beim ersten Laden deaktiviert sein, um zu verhindern, dass die von Sequenz generierten Werte von Oracle überschrieben werden. Fügen Sie das Attribut AUTO_INCREMENT zur Primärschlüsselspalte hinzu, nachdem der anfängliche Ladevorgang abgeschlossen ist.
  • Netzwerkverbindung: Wenn Sie CDC verwenden, achten Sie darauf, dass sowohl die Quell- als auch die Zielumgebung eine Netzwerkverbindung zum CDC-Produkt herstellen kann, um die Datenerfassung auf Oracle-Seite und das Laden von Daten auf Cloud SQL for MySQL-Seite zu ermöglichen.

Anwendungsfall „GoldenGate“

In diesem Abschnitt wird genauer erläutert, wie eine Onlinemigration zu Cloud SQL aus dem CIC-Angebot von Oracle, GoldenGate, besteht. Der erste Schritt besteht darin, die Umgebung für GoldenGate vorzubereiten, indem Sie GoldenGate sowohl im Quell- als auch im Zielsystem installieren. Auf der Quellseite können Sie die Anwendung entweder auf dem Oracle-Server oder auf einem Remote-Server installieren, der über eine SQL*Net-Verbindung mit der Oracle-Datenbank verbunden wird. Auf der Zielseite müssen Sie eine Staging-VM in Google Cloud ausführen, um die GoldenGate-Anwendung auszuführen, da Sie GoldenGate nicht direkt auf der Cloud SQL-Maschine installieren können. GoldenGate versendet mit dem Befehlszeilenprogramm GGSCI die Konfiguration verschiedener GoldenenGate-Prozesse.

Sobald die Umgebung eingerichtet ist, konfigurieren und fügen Sie den EXTRACT-Prozess zum Erfassen von Datenänderungen hinzu. Dies erfolgt vor dem Start des anfänglichen Datenladevorgangs, damit laufende Transaktionsänderungen nicht während der Ausführung verloren gehen. Wie bereits erwähnt, müssen bei CDC zusätzliche Logging-Vorgänge in der Oracle-Quelldatenbank aktiviert sein. Die zugesicherten Transaktionen werden aus den Redo-Logs erfasst, in logical change records (LCRs) übersetzt und in die lokalen Dateien in den Remote-Staging-Bereich (Google Cloud-VM) geschrieben. Sie müssen herausfinden, wie Sie die Pfaddateien so anpassen, dass sie lange genug laufen, ohne den gesamten verfügbaren Speicherplatz zu verbrauchen.

Im nächsten Schritt konfigurieren Sie das GoldenGate-Erfassungsverfahren namens EXTRACT, um den anfänglichen Ladevorgang der Daten auszuführen. Dazu gehört das Erstellen einer Parameterdatei, die eine Auflistung von Zuordnungen zwischen den Quelltabellen in Oracle und den Zieltabellen in MySQL angibt (z. B. MAP schema/table to TARGET database.table). Im Gegensatz zu CDC verwendet der anfängliche Ladevorgang die Quelltabellen und nicht die Redo-Logs, um die Quelldaten abzuleiten. Wir führen den anfänglichen Ladevorgang aus, indem wir den Prozess EXTRACT starten und die Ergebnisse prüfen. Die Dauer des anfänglichen Ladevorgangs wird sich auf das Datenvolumen und den Netzwerkdurchsatz auswirken.

Nachdem der anfängliche Datenladevorgang erfolgreich abgeschlossen wurde, konfigurieren Sie die Änderung der Bereitstellung, mit der LCRs auf die MySQL-Zieldatenbank angewendet wird. Beim REPLICAT-Prozess werden diese Datensätze aus den Remote-Trail-Dateien gelesen, in DML- und DDL-Anweisungen konvertiert und auf die MySQL-Zieldatenbank angewendet. Der REPLICAT-Prozess hat eine eigene Parameterdatei, die einen Abschnitt zum Umgang mit Konflikten und anderen Ausnahmen enthält.

Die einfachste Möglichkeit, festzustellen, ob die Datenreplikation funktioniert, besteht darin, eine Zeilenanzahl für eine Quelltabelle auszuführen und die Ergebnisse mit ihrer Zieltabelle zu vergleichen. GGSCI enthält einen Berichts- und Statistikbefehl, mit dem Sie Replikationsstatistiken und Fehler aufrufen können.

Erfolgskriterien

Die Datenmigration (offline oder online) darf nur dann als erfolgreich gelten, wenn die folgenden Kriterien erfüllt sind:

  • Die Datenübertragungen wurden ohne Fehler oder Prozessausfälle ausgeführt.
  • Bei Verwendung eines einmaligen Ladevorgangs überstieg die Dauer des Ladevorgangs nicht das für Ihr Unternehmen zulässige Ausfallzeitfenster.
  • Bei Verwendung von CDC stellten Ihre Anwendungsnutzer während des anfänglichen Ladevorgangs keine Leistungseinbußen fest.
  • Bei Verwendung von CDC verkürzte sich die Replikationsverzögerung im Laufe der Zeit so, dass die Zieldatenbank die Quelldatenbank schließlich aufholte.

Datenintegrität nach der Migration prüfen

In dieser Phase werden Probleme und Inkonsistenzen in der MySQL-Zielumgebung ermittelt, damit etwaige Abweichungen zwischen den Daten schnell behoben werden können. Gehen Sie so vor:

  1. Vergleichen Sie die Anzahl der Zeilen zwischen den Quell- und Zieldatenbanktabellen, um Lücken zu erkennen. Führen Sie nicht nur count, sondern auch sum, avg, min und max für denselben Satz von Tabellen aus.
  2. Führen Sie häufig verwendete SQL-Anweisungen für die MySQL-Zielumgebung aus, damit die Daten der Oracle-Quelldatenbank entsprechen.
  3. Verbinden Sie die Anwendung mit den Quell- und Zieldatenbanken und prüfen Sie, ob die Ergebnisse übereinstimmen.

Nächste Schritte