View a markdown version of this page

Übersicht - AWS Präskriptive Leitlinien

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Übersicht

Dies ist der konzeptionelle Prozess der Migration von Oracle-Datenbanken zur AWS Verwendung inkrementeller Oracle XTTS- und RMAN-Backups mit Snowball Edge und für Lustre. Direct Connect FSx

Das folgende Diagramm zeigt die allgemeinen Migrationsschritte für eine Oracle-Datenbank in verschiedenen Endian-Formaten.

Die Beschreibung finden Sie in der nummerierten Liste nach dem Diagramm.
  1. Erstellen Sie eine vollständige Sicherung aller Tablespaces.

  2. Verwenden Sie Snowball Edge, um das Backup von der Quellphase in die Zielphase zu verschieben.

  3. Konvertiert die Tablespaces in die Zieldatenbank.

  4. Erstellen Sie inkrementelle Backups.

  5. Wird verwendet Direct Connect , um inkrementelle Backups von der Quellphase in die Zielphase zu übertragen.

  6. Führen Sie ein Rollforward der inkrementellen Backups durch, konvertieren Sie sie und wenden Sie sie auf die Zieldatenbank an.

  7. Exportieren und importieren Sie Metadaten für alle Tablespaces, die transportiert werden.

Vor der Umstellung können Sie die Ausfallzeit minimieren, indem Sie wie folgt vorgehen:

  • Exportieren und Importieren der Metadaten von Objekten, die nicht segmentbasiert sind, einschließlich,USER, und PACKAGE_SPEC PACKAGE_BODY PROCEDURE FUNCTION

  • Zunehmende Parallelität für vollständige Backups und inkrementelle Backups

  • Datendateien werden konvertiert

  • Backups während der Migration weiterleiten

In dem Oracle-Dokument Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (2471245.1) wird erklärt, wie Oracle XTTS mit inkrementellen RMAN-Backups verwendet wird. Das Dokument enthält auch Einzelheiten zu Anforderungen und Empfehlungen. In dem Dokument wird nicht beschrieben, wie eine Oracle-Datenbank von einer lokalen Umgebung zu Oracle on migriert wird AWS oder wie die einzelnen Migrationsschritte parallelisiert werden, um Ausfallzeiten zu minimieren.

Dieses Handbuch bietet eine Möglichkeit, die Phasen zu parallelisieren und so die Ausfallzeiten bei der Migration in unternehmenskritischen Systemumgebungen mit enorm großen Datenmengen zu minimieren.

Nach einer ersten Einrichtungsphase umfassen die allgemeinen Schritte zur Verwendung von Oracle XTTS mit inkrementellen RMAN-Backups die folgenden Phasen.

Phase 1 — Vorbereitungsphase

Die Vorbereitungsphase besteht aus den folgenden Schritten:

  1. Ein erstes vollständiges Backup (Stufe = 0) der Tablespaces wird in der Quelldatenbank in die Quellstufe übertragen, bei der es sich um den NAS-Speicher handelt.

  2. Die Sicherungskopien werden mit Snowball Edge auf die Zielstufe übertragen, die FSx für Lustre in Amazon Simple Storage Service (Amazon S3) integriert ist.

  3. Backup-Tablespaces werden wiederhergestellt und im Little-Endian-Format in die Zieldatenbank konvertiert.

Die Schritte in dieser Phase werden während der Migration nur einmal ausgeführt. Die transportierten Daten sind in dieser Phase in der Quelldatenbank vollständig zugänglich.

Phase 2 — Roll-Forward-Phase

Die Roll-Forward-Phase besteht aus den folgenden Schritten:

  1. Ein inkrementelles Backup wird von der Quelldatenbank in die Quellphase übertragen.

  2. Inkrementelle Sicherungskopien werden erneut in die Zielphase übertragen. Direct Connect

  3. Inkrementelle Sicherungskopien werden im Little-Endian-Format in die Zieldatenbank konvertiert. Die Kopien werden dann auf die ursprüngliche Zieldatenbank angewendet, was als Roll-Forward-Schritt bezeichnet wird.

Sie können diese Phase mehrmals ausführen. Jede aufeinanderfolgende inkrementelle Sicherung sollte weniger Zeit in Anspruch nehmen und die Kopien der Zieldatendatei mit der Quelldatenbank auf den neuesten Stand bringen. Wie in Phase 1 ist der Zugriff auf die zu transportierenden Quelldaten in dieser Phase vollständig möglich.

Phase 3 — Transportphase

Die dritte Phase umfasst die folgenden Schritte:

  1. Die zu transportierenden Tablespaces werden so geändert, dass sie nur noch lesbar sind.

  2. Eine letzte inkrementelle Sicherung wird aus der Quelldatenbank erstellt.

  3. Die Metadaten werden exportiert.

  4. Backups werden übertragen und auf das Ziel angewendet.

  5. Objektmetadaten werden importiert.

Zu diesem Zeitpunkt stimmt die Systemänderungsnummer (SCN) der Zieldatenbank mit der der Quelldatenbank überein.

Die Metadaten der transportierbaren Tablespaces werden aus der Quelldatenbank exportiert und in die Zieldatenbank importiert. Die Metadaten enthalten Informationen für den Benutzer, die Rolle, das Paket, die Prozedur, die Funktion, die Tabelle und den Index.

Schließlich werden die Tablespaces mit Lese-/Schreibzugriff versehen, um von der Anwendung aus vollen Zugriff auf die Zieldatenbank zu erhalten.

Auf diese Phase folgt eine Validierungsphase.