Bekannte Einschränkungen und Empfehlungen

Auf dieser Seite werden bekannte Einschränkungen (einschließlich spezieller Hinweise zur Verarbeitung von Entitäten wie Primärschlüsseln oder Fremdschlüsseln und Triggern) sowie empfohlene Praktiken für heterogene Oracle-Migrationen mit Database Migration Service beschrieben.

Was nicht migriert wird

  • Nutzer und Berechtigungen werden nicht migriert.
  • Schemaänderungen, die während eines aktiven Migrationsjobs auftreten, werden nicht automatisch migriert. Wenn Sie das Schema während der Migration ändern, müssen Sie zuerst den Konvertierungsarbeitsbereich mit den Schemaänderungen aktualisieren und dann die entsprechenden Migrationsjobs aktualisieren. Weitere Informationen finden Sie unter Aktualisiertes Schema oder Tabellen zum Migrationsjob hinzufügen.
  • SAVEPOINT-Anweisungen werden nicht unterstützt und können bei einem Rollback zu Datenabweichungen führen.
  • Der Database Migration Service repliziert benutzerdefinierte Datentypen, speichert aber nur den Basisdatentyp, aus dem Sie Ihre benutzerdefinierten Typen ableiten. Wenn Sie beispielsweise einen USERNAME-Datentyp basierend auf dem VARCHAR2-Datentyp definieren, werden die Daten im Ziel als VARCHAR gespeichert.

Datenbank, Transaktionen und Datenkonsistenz

  • Die Migration ist schlussendlich konsistent, da der Database Migration Service nicht jede Transaktion bei ihrem Auftreten repliziert. Bei der Migration werden Daten aus mehreren Tabellen importiert. Die Reihenfolge, in der Daten in das Ziel geladen werden, kann variieren, wird aber wieder an die Quelle angeglichen, nachdem die Schreibvorgänge in der Quelle beendet und der Migrationsbuffer gelöscht wurden.
  • Bei heterogenen Oracle-Migrationen kann der Database Migration Service nur eine Datenbank pro Migrationsjob migrieren.
  • Der Database Migration Service unterstützt die mehrmandantenfähige Architektur von Oracle (CDB/PDB). Sie können jedoch nur eine einzelne Plug-in-Datenbank pro Migrationsjob migrieren.
  • Oracle Label Security (OLS) wird nicht repliziert.
  • Die Zieldatenbank muss denselben Namen wie der Nutzername haben, der für die Verbindung mit der Datenbank verwendet wird.
  • Transaktionen, die während des Migrationsprozesses in der Quelldatenbank rückgängig gemacht werden, sind möglicherweise vorübergehend im Ziel zu sehen, wenn die Transaktion lang genug ist.
  • Der Database Migration Service unterstützt keine direkte Verbindung zu Datenbanken, die die Funktion „Single Client Access Name“ (SCAN) in Oracle Real Application Cluster-Umgebungen (RAC) verwenden. Informationen zu möglichen Lösungen für die Verwendung von Verbindungen mit Zulassungslisten für öffentliche IP-Adressen in solchen Umgebungen finden Sie unter Fehlerbehebung bei Oracle SCAN-Fehlern.

Datencodierung

  • Der Database Migration Service unterstützt nur UTF8-Codierungen für die Zieldatenbank. Schema- und Tabellennamen, die Zeichen enthalten, die nicht zum UTF8-Codierungssatz gehören, werden nicht unterstützt.
  • Der Database Migration Service unterstützt die folgenden Zeichensatzcodierungen für Oracle-Datenbanken:
    • AL16UTF16
    • AL32UTF8
    • IN8ISCII
    • JA16SJIS
    • US7ASCII
    • UTF8
    • WE8ISO8859P1
    • WE8ISO8859P9
    • WE8ISO8859P15
    • WE8MSWIN1252
    • ZHT16BIG5

Tabellen, Schemas und andere Objekte

  • Während einer Migration werden keine DDL-Änderungen (Data Definition Language) an Daten, Schemas und Metadaten unterstützt. Wenn Sie Ihr Schema während der Migration aktualisieren, müssen Sie die Änderungen in Ihren Konvertierungsarbeitsbereich übertragen, den Code konvertieren, das Ziel bereinigen und den Migrationsjob noch einmal ausführen.
  • Spaltennamen von Tabellen, die andere Zeichen als alphanumerische Zeichen oder einen Unterstrich (_) enthalten, werden nicht unterstützt.
  • Indexbasierte Tabellen (Index-organized Tables, IOTs) werden nicht unterstützt.
  • Für globale temporäre Tabellen muss die pgtt-PostgreSQL-Erweiterung am Ziel installiert und erstellt werden.
  • Bei Spalten vom Typ BFILE wird nur der Pfad zur Datei repliziert. Der Inhalt der Datei wird nicht repliziert.
  • Bei Oracle 11g werden Tabellen mit Spalten vom Datentyp ANYDATA oder UDT nicht unterstützt und die gesamte Tabelle wird nicht repliziert.
  • Jobs, die mit dbms_job oder dbms_scheduler geplant werden, werden nicht migriert.
  • Die Definitionen von materialisierten Ansichten werden migriert, die materialisierten Daten jedoch nicht. Aktualisieren Sie nach Abschluss der Migration Ihre materialisierten Ansichten, um sie mit Daten aus den migrierten Tabellen zu füllen.
  • Sequenzwerte werden migriert, ihre Werte in der Quelldatenbank können jedoch weiter ansteigen, bevor die Migration abgeschlossen ist. Aktualisieren Sie nach Abschluss der Migration die Sequenzwerte in der Zielinstanz, damit sie mit denen in der Quelldatenbank übereinstimmen.
  • Migrationsjobs sind auf 10.000 Tabellen beschränkt.
  • Zeilen dürfen maximal 100 MB groß sein. Zeilen, die das Limit von 100 MB überschreiten, werden nicht migriert und im Migrationsjob als Fehler angezeigt.
  • Tabellen, die nach Beginn der Migration erstellt werden, werden nicht automatisch migriert. Sie müssen zuerst das Schema in den Konvertierungsarbeitsbereich abrufen, die konvertierten Definitionen auf das Ziel anwenden und den Migrationsjob aktualisieren.

Datentypbeschränkungen

Die folgenden Datentypen werden bei Oracle-Migrationen nicht unterstützt:

  • ANYDATA (Bei Oracle 11g werden Tabellen mit ANYDATA nicht unterstützt und nicht repliziert.)
  • BFILE
  • INTERVAL DAY TO SECOND
  • INTERVAL YEAR TO MONTH
  • LONG/LONG RAW
  • SDO_GEOMETRY
  • UDT
  • UROWID
  • XMLTYPE
  • Null-Tage in TIMESTAMP

Überlegungen zu Primärschlüsseln

Bei Tabellen ohne Primärschlüssel ist keine konsistente Replikation möglich. Database Migration Service migriert nur Tabellen mit Primärschlüsseln. Wenn Ihre Quelldatenbank Tabellen ohne Primärschlüssel enthält, werden in den Konvertierungsarbeitsbereichen des Database Migration Service automatisch fehlende Primärschlüssel in den Zieltabellen erstellt, wenn Sie Ihren Quellcode und Ihr Schema konvertieren.

Wenn Sie alte Conversion-Arbeitsbereiche verwenden, müssen Sie in den konvertierten Tabellen in der Zieldatenbank manuell Primärschlüsseleinschränkungen erstellen, bevor Sie mit der Migration beginnen. Weitere Informationen finden Sie unter Legacy-Konvertierungsarbeitsbereiche.

Überlegungen zu Fremdschlüsseln und Triggern

Fremdschlüssel und Trigger in Ihrer Quelldatenbank können zu Problemen mit der Datenintegrität oder sogar zum Fehlschlagen des Migrationsjobs führen. Sie können diese Probleme vermeiden, indem Sie Fremdschlüssel und Trigger mit der Option REPLICATION für den Migrationsnutzer überspringen. Alternativ können Sie auch alle Fremdschlüssel und Trigger in der Zieldatenbank löschen und sie nach Abschluss der Migration neu erstellen.

Trigger

In den vom Database Migration Service replizierten Daten sind bereits alle Änderungen enthalten, die durch Trigger in der Quelldatenbank vorgenommen wurden. Wenn Trigger für das Ziel aktiviert sind, können sie noch einmal ausgelöst und Daten möglicherweise manipuliert werden, was zu Problemen mit der Datenintegrität oder Datenduplizierung führen kann.

Fremdschlüssel

Der Database Migration Service repliziert Daten nicht transaktional. Daher werden Tabellen möglicherweise nicht in der richtigen Reihenfolge migriert. Wenn Fremdschlüssel vorhanden sind und eine untergeordnete Tabelle, die einen Fremdschlüssel verwendet, vor ihrer übergeordneten Tabelle migriert wird, können Replikationsfehler auftreten.

Empfehlungen

  • Achten Sie beim Erstellen der Ziel-Cloud SQL-Datenbank darauf, dass Sie genügend Rechen- und Arbeitsspeicherressourcen für Ihre Migrationsanforderungen verwenden. Wir empfehlen einen Maschinentyp mit mindestens einer Dual-Core-CPU.

    Wenn Ihr Maschinenname beispielsweise db-custom lautet und die Maschine 2 CPUs und 3.840 MB RAM hat, lautet das Format für den Maschinentypnamen db-custom-2-3840.

  • Die Ziel-Cloud SQL-Datenbank ist während der Migration beschreibbar, damit bei Bedarf DML-Änderungen (Data Manipulation Language) angewendet werden können. Achten Sie darauf, keine Änderungen an der Datenbankkonfiguration oder den Tabellenstrukturen vorzunehmen, die den Migrationsprozess unterbrechen oder die Datenintegrität beeinträchtigen könnten.

Kontingente

  • Es können immer bis zu 2.000 Verbindungsprofile und 1.000 Migrationsjobs gleichzeitig vorhanden sein. Wenn Platz für weitere Jobs und Profile benötigt wird, können Migrationsjobs (einschließlich bereits abgeschlossene) und Verbindungsprofile gelöscht werden.