Bekannte Einschränkungen und Empfehlungen

Auf dieser Seite werden bekannte Einschränkungen (einschließlich besonderer Überlegungen zum Umgang mit Entitäten wie Primärschlüsseln oder Fremdschlüsseln und Triggern) sowie empfohlene Vorgehensweisen für heterogene Oracle-Migrationen mit Database Migration Service beschrieben.

Was wird nicht migriert?

  • Nutzer und Berechtigungen werden nicht migriert.
  • Schemaänderungen, die während eines aktiven Migrationsjobs auftreten, werden nicht automatisch migriert. Wenn Sie Ihr Schema während der Migration ändern, müssen Sie zuerst den Konvertierungsarbeitsbereich mit den Schemaänderungen aktualisieren und dann die relevanten Migrationsjobs aktualisieren. Weitere Informationen finden Sie unter Aktualisiertes Schema oder aktualisierte Tabellen zum Migrationsjob hinzufügen.
  • SAVEPOINT-Anweisungen werden nicht unterstützt und können im Falle eines Rollbacks zu Datenabweichungen führen.
  • Database Migration Service repliziert benutzerdefinierte Datentypen, speichert aber nur den Basisdatentyp, von 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 letztendlich konsistent, da Database Migration Service nicht jede Transaktion repliziert, wenn sie auftritt. Bei der Migration werden Daten aus mehreren Tabellen importiert. Die Reihenfolge, in der Daten in das Ziel geladen werden, kann variieren, wird aber wieder mit der Quelle abgeglichen, nachdem Schreibvorgänge in der Quelle beendet wurden und der Migrationspuffer geleert wurde.
  • Bei heterogenen Oracle-Migrationen kann Database Migration Service nur eine Datenbank pro Migrationsjob migrieren.
  • 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.
  • Alle Transaktionen, die während des Migrationsprozesses in der Quelldatenbank zurückgesetzt werden, sind möglicherweise vorübergehend im Ziel sichtbar (wenn die Transaktion lang genug ist).
  • Database Migration Service unterstützt keine direkte Verbindung zu Datenbanken über die SCAN-Funktion (Single Client Access Name) in Oracle Real Application Clusters (RAC)-Umgebungen. Mögliche Lösungen für die Verwendung der Verbindung über eine Zulassungsliste für öffentliche IP-Adressen mit solchen Umgebungen finden Sie unter Oracle SCAN-Fehler beheben.

Datencodierung

  • Database Migration Service unterstützt nur UTF8-Codierungen für die Zieldatenbank. Schema- und Tabellennamen, die Zeichen enthalten, die nicht Teil des UTF8-Codierungssatzes sind, werden nicht unterstützt.
  • Database Migration Service unterstützt die folgenden Zeichensatzcodierungen für Oracle-Datenbanken:
    • AL16UTF16
    • AL32UTF8
    • IN8ISCII
    • IW8ISO8859P8
    • JA16SJIS
    • JA16SJISTILDE
    • KO16MSWIN949
    • US7ASCII
    • UTF8
    • WE8ISO8859P1
    • WE8ISO8859P9
    • WE8ISO8859P15
    • WE8MSWIN1252
    • ZHT16BIG5

Tabellen, Schemas und andere Objekte

  • Während einer Migration werden Änderungen an Daten, Schemas und Metadaten, die mit der Datendefinitionssprache (DDL) vorgenommen werden, nicht 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.
  • Tabellenspaltennamen, die andere Zeichen als alphanumerische Zeichen oder einen Unterstrich (_) enthalten, werden nicht unterstützt.
  • Die maximale Länge für Tabellen- oder Spaltennamen beträgt 30 Zeichen. kann Database Migration Service keine Tabellen replizieren, die dieses Limit überschreiten, oder Tabellen, die Spalten enthalten, deren Namen dieses Limit überschreiten.
  • Indexbasierte Tabellen (Index-organized Tables, IOTs) werden nicht unterstützt.
  • Für globale temporäre Tabellen muss die PostgreSQL-Erweiterung pgtt auf dem Ziel installiert und erstellt werden.
  • Bei Spalten vom Typ BFILE wird nur der Pfad zur Datei repliziert. Der Inhalt der Datei wird nicht repliziert.
  • Für Oracle 11g werden Tabellen mit Spalten der Datentypen ANYDATA oder UDT nicht unterstützt und die gesamte Tabelle wird nicht repliziert.
  • Jobs, die mit dbms_job oder dbms_scheduler geplant sind, werden nicht migriert.
  • Definitionen von materialisierten Ansichten werden migriert, die materialisierten Daten jedoch nicht. Aktualisieren Sie nach der Migration Ihre materialisierten Ansichten, um sie mit Daten aus den migrierten Tabellen zu füllen.
  • Sequenzwerte werden migriert, aber ihre Werte in der Quelldatenbank können sich vor Abschluss der Migration weiter erhöhen. Aktualisieren Sie nach Abschluss der Migration die Sequenzwerte auf der Zielinstanz, sodass sie mit denen in der Quelldatenbank übereinstimmen.
  • Migrationsjobs sind auf 10.000 Tabellen beschränkt.
  • Zeilen haben eine Größenbeschränkung von 100 MB. 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. Zuerst müssen Sie das Schema in den Konvertierungsarbeitsbereich ziehen, konvertierte Definitionen auf das Ziel anwenden und den Migrationsjob aktualisieren.
  • Quelltabellen, die binäre Spalten enthalten und keine Primärschlüssel haben, werden für die Datenmigration in kontinuierlichen Migrationen nicht unterstützt.
  • Virtuelle Spalten (GENERATED ALWAYS AS (...) VIRTUAL) werden während der Datenmigration nicht repliziert, da Oracle keine Werte für virtuelle Spalten in Redo-Logs schreibt. Wenn eine virtuelle Spalte Teil eines zusammengesetzten Primärschlüssels ist, werden während der Replikation nur die nicht virtuellen Spalten als Primärschlüssel verwendet.

Datentypbeschränkungen

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

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

Überlegungen zu Primärschlüsseln

Bei Tabellen ohne Primärschlüssel ist keine konsistente Replikation gewährleistet. Database Migration Service migriert nur Tabellen mit Primärschlüsseln. Wenn Ihre Quelldatenbank Tabellen ohne Primärschlüssel enthält, werden in den Konvertierungsarbeitsbereichen von Database Migration Service automatisch alle fehlenden Primärschlüssel in den Zieltabellen erstellt, wenn Sie Ihren Quellcode und Ihr Schema konvertieren. Für diesen automatisierten Prozess müssen Ihre Quelltabellen folgende Voraussetzungen erfüllen:

  • Sie haben noch keine Primärschlüssel.
  • Verwenden Sie keine UNIQUE-Einschränkung ohne Spalten, die Nullwerte enthalten können.
  • Verwenden Sie keinen UNIQUE-Index ohne Spalten, die Nullwerte enthalten können.

Wenn Ihre Tabellen diese Anforderungen nicht erfüllen, müssen Sie die fehlenden Primärschlüssel manuell zu den Tabellen im konvertierten PostgreSQL-Schema hinzufügen. Sie können die automatische Primärschlüsselgenerierung auch mit der Konvertierungsanweisung GENERATE_MISSING_PK deaktivieren.

Für kontinuierliche Migrationen: Quelltabellen, die binäre Spalten enthalten und keine Primärschlüssel haben, werden für die Datenmigration in kontinuierlichen Migrationen nicht unterstützt.

Wenn Sie Legacy-Konvertierungsarbeitsbereiche verwenden, müssen Sie vor Beginn der Migration manuell Primärschlüsseleinschränkungen in den konvertierten Tabellen in der Zieldatenbank erstellen. 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, wenn Sie Fremdschlüssel und Trigger überspringen, indem Sie die Option REPLICATION für den Migrationsnutzer verwenden. Alternativ können Sie auch alle Fremdschlüssel und Trigger in der Zieldatenbank löschen und nach Abschluss der Migration neu erstellen.

Trigger

Von Database Migration Service replizierte Daten enthalten bereits alle Änderungen, die durch Trigger in der Quelldatenbank vorgenommen wurden. Wenn Trigger am Ziel aktiviert sind, können sie noch einmal ausgelöst werden und möglicherweise Daten manipulieren, was zu Problemen mit der Datenintegrität oder Duplizierung führen kann.

Fremdschlüssel

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

Empfehlungen

  • Achten Sie beim Erstellen der Cloud SQL-Zieldatenbank 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 Cloud SQL-Zieldatenbank ist während der Migration beschreibbar, damit bei Bedarf Änderungen mit der Datenbearbeitungssprache (Data Manipulation Language, DML) vorgenommen 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 jeweils bis zu 2.000 Verbindungsprofile und 1.000 Migrationsjobs vorhanden sein. Wenn Sie Platz für weitere Migrationsjobs schaffen möchten, können Sie Migrationsjobs (auch abgeschlossene) und Verbindungsprofile löschen.