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 Empfehlungen 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 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 Migrationsjob aktualisiertes Schema oder Tabellen hinzufügen.
  • SAVEPOINT-Anweisungen werden nicht unterstützt und können im Falle eines Rollbacks zu Datenabweichungen führen.
  • Der Database Migration Service repliziert nutzerdefinierte Datentypen, speichert aber nur den Basisdatentyp, aus dem Sie Ihre nutzerdefinierten 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 letztlich konsistent, da Database Migration Service nicht jede Transaktion repliziert, sobald sie erfolgt. Bei der Migration werden Daten aus mehreren Tabellen übernommen. Die Reihenfolge, in der Daten in das Ziel geladen werden, kann variieren. Sie wird jedoch wieder an die Quelle angeglichen, nachdem Schreibvorgänge in der Quelle beendet 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), aber Sie können nur eine einzelne Plug-in-Datenbank pro Migrationsjob migrieren.
  • Oracle Label Security (OLS) wird nicht repliziert.
  • Alle Transaktionen, die während der Migration in Ihrer Quelldatenbank zurückgesetzt werden, sind möglicherweise vorübergehend in der Zieldatenbank sichtbar, wenn die Transaktion lang genug ist.
  • Database Migration Service unterstützt keine direkte Verbindung zu Datenbanken, die das SCAN-Feature (Single Client Access Name) in Oracle RAC-Umgebungen (Real Application Clusters) verwenden. Mögliche Lösungen für die Verwendung von Verbindungen mit Zulassungsliste 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-Zeichensätze 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 Ihren 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.
  • Tabellen- oder Spaltennamen dürfen maximal 30 Zeichen lang sein. Database Migration Service kann 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 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.
  • 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 sind, werden nicht migriert.
  • Definitionen von materialisierten Ansichten werden migriert, die materialisierten Daten jedoch nicht. Nach Abschluss der Migration müssen Sie Ihre materialisierten Ansichten aktualisieren, damit sie mit Daten aus den migrierten Tabellen gefüllt werden.
  • Sequenzwerte werden migriert, aber ihre Werte in der Quelldatenbank können sich vor Abschluss der Migration weiter erhöhen. Nach Abschluss der Migration müssen Sie die Sequenzwerte in der Zielinstanz so aktualisieren, dass 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 als Fehler im Migrationsjob angezeigt.
  • Tabellen, die nach dem Start 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.

Datentypbeschränkungen

Die folgenden Datentypen werden für 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
  • Nulltage 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.

Wenn Sie Legacy-Conversion-Arbeitsbereiche verwenden, müssen Sie vor Beginn der Migration manuell Primärschlüsselbeschrä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 führen oder sogar dazu, dass der Migrationsjob fehlschlägt. 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 sie nach Abschluss der Migration neu erstellen.

Trigger

Daten, die von Database Migration Service repliziert werden, enthalten bereits alle Änderungen, die durch Trigger 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 transaktional, sodass Tabellen möglicherweise in falscher 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 Ihrer Cloud SQL-Zieldatenbank darauf, dass Sie genügend Rechen- und Arbeitsspeicherressourcen für die Migration bereitstellen. 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 an der Datenbearbeitungssprache (Data Manipulation Language, DML) angewendet werden können. Nehmen Sie keine Änderungen an der Datenbankkonfiguration oder den Tabellenstrukturen vor, 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.