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 entsprechenden Migrationsjobs aktualisieren. Weitere Informationen finden Sie unter Aktualisiertes Schema oder aktualisierte Tabellen zum Migrationsjob hinzufügen.
  • SAVEPOINT statements 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, sobald sie stattfindet. Bei der Migration werden Daten aus mehreren Tabellen übernommen. Die Reihenfolge, in der Daten in das Ziel geladen werden, kann variieren, wird aber nach dem Beenden der Schreibvorgänge in der Quelle und dem Leeren des Migrationspuffers wieder an die Quelle angepasst.
  • 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), aber Sie können nur eine einzelne Pluggable Database pro Migrationsjob migrieren.
  • Oracle Label Security (OLS) wird nicht repliziert.
  • Alle Transaktionen, die während der Migration 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 mit dem Feature Single Client Access Name (SCAN) in Oracle Real Application Clusters (RAC)-Umgebungen. Mögliche Lösungen für die Verwendung der Allowlist für öffentliche IP-Adressen mit solchen Umgebungen finden Sie unter Fehlerbehebung bei Oracle SCAN-Fehlern.

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 DDL-Änderungen (Data Definition Language, Datendefinitionssprache) an Daten, Schemas, und Metadaten nicht unterstützt. Wenn Sie Ihr Schema während der Migration aktualisieren, müssen Sie die Änderungen in den Konvertierungsarbeitsbereich übernehmen, 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 mit Namen enthalten, die dieses Limit überschreiten.
  • Indexbasierte Tabellen (Index-organized Tables, IOTs) werden nicht unterstützt.
  • Für globale temporäre Tabellen muss die pgtt PostgreSQL Erweiterung im Ziel installiert und erstellt sein.
  • Bei Spalten vom Typ BFILE wird nur der Pfad zur Datei repliziert. Die Inhalte der Datei werden 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 wurden, werden nicht migriert.
  • Definitionen materialisierter Ansichten werden migriert, die materialisierten Daten jedoch nicht. Nach Abschluss der Migration müssen Sie die materialisierten Ansichten aktualisieren, um sie mit Daten aus den migrierten Tabellen zu füllen.
  • Sequenzwerte werden migriert, aber ihre Werte in der Quelldatenbank können sich weiter erhöhen, 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 haben eine Größenbeschränkung von 100 MB. Zeilen, die das Limit von 100 MB überschreiten, werden nicht migriert und als Fehler im Migrationsjob angezeigt.
  • Alle Tabellen, die nach Beginn der Migration erstellt werden, werden nicht automatisch migriert. Zuerst müssen Sie ihr Schema in den Konvertierungsarbeitsbereich übernehmen, konvertierte Definitionen auf das Ziel anwenden und den Migrationsjob aktualisieren.
  • Quelltabelle mit binären Spalten ohne Primärschlüssel werden nicht unterstützt für die Datenmigration bei kontinuierlichen Migrationen.

Datentypbeschränkungen

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

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

Überlegungen zu Primärschlüsseln

Bei Tabellen ohne Primärschlüssel kann keine konsistente Replikation garantiert werden. 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 die Quelltabellen folgende Voraussetzungen erfüllen:

  • Sie dürfen keine Primärschlüssel haben.
  • Sie dürfen keine UNIQUE-Einschränkung ohne Spalten mit Nullwerten haben.
  • Sie dürfen keinen UNIQUE-Index ohne Spalten mit Nullwerten haben.

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 GENERATE_MISSING_PK Konvertierungsanweisung deaktivieren.

Bei kontinuierlichen Migrationen: Quelltabelle mit binären Spalten und ohne Primärschlüssel werden für die Datenmigration bei 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 der Quelldatenbank können zu Problemen mit der Datenintegrität führen oder sogar dazu, dass der Migrationsjob fehlschlägt. Sie können diese Probleme vermeiden, indem 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 sie nach Abschluss der Migration neu erstellen.

Trigger

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

Fremdschlüssel

Database Migration Service repliziert Daten nicht transaktionsweise, sodass Tabellen möglicherweise in der falschen 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

  • Wenn Sie Ihre Cloud SQL-Zieldatenbank erstellen, müssen Sie genügend Compute- und Arbeitsspeicherressourcen verwenden, um Ihre Migrationsanforderungen zu erfüllen. 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 Maschinennamen db-custom-2-3840.

  • Die Cloud SQL-Zieldatenbank ist während der Migration beschreibbar , sodass bei Bedarf DML-Änderungen (Data Manipulation Language, Datenbearbeitungssprache) angewendet werden können. Nehmen Sie keine Änderungen an der Datenbankkonfiguration oder den Tabellen strukturen vor, da dies den Migrationsprozess unterbrechen oder die Datenintegrität beeinträchtigen kann.

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.