Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
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.
Die Zieldatenbank muss denselben Namen haben wie der Nutzername, der für die Verbindung zur Datenbank verwendet wird.
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.
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.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-18 (UTC)."],[[["\u003cp\u003eDatabase Migration Service has limitations on supported characters, including only allowing \u003ccode\u003eUTF8\u003c/code\u003e encoding for the destination database, and not supporting table column names with non-alphanumeric characters or anything other than an underscore.\u003c/p\u003e\n"],["\u003cp\u003eThe service restricts migration jobs to a maximum of 10,000 tables, and only supports single pluggable database migration for Oracle multi-tenant architecture.\u003c/p\u003e\n"],["\u003cp\u003eCertain Oracle features, such as Index-organized tables, Oracle Autonomous Database, \u003ccode\u003eBFILE\u003c/code\u003e types, and many other data types are not supported or will be replaced with NULL values, and scheduled jobs or schema changes won't be migrated either.\u003c/p\u003e\n"],["\u003cp\u003eUp to 2,000 connection profiles and 1,000 migration jobs can exist at any given time, but if more is needed then previously completed migration jobs and connection profiles can be deleted.\u003c/p\u003e\n"],["\u003cp\u003eDirect connectivity to databases using Oracle Real Application Clusters (RAC) Single Client Access Name (SCAN) is not supported by Database Migration Service, and there is also a 100 MB row size limitation.\u003c/p\u003e\n"]]],[],null,["# Known limitations and recommendations\n\nThis page describes known limitations (including special considerations for\nhandling entities like\n[primary keys](#primary-keys-considerations) or\n[foreign keys and triggers](#foreign-keys-triggers-considerations)), as well as\n[recommended practices](#) for heterogeneous Oracle migrations with Database Migration Service.\n\nWhat isn't migrated\n-------------------\n\n- Users and permissions aren't migrated.\n- Schema changes that occur during an active migration job aren't automatically migrated. If you change your schema during the migration, you need to first update the conversion workspace with schema changes, and then refresh the relevant migration jobs. For more information, see [Add updated schema or tables to the migration job](/database-migration/docs/oracle-to-alloydb/manage-migration-jobs#edit-non-draft-job).\n- [`SAVEPOINT` statements](https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/SAVEPOINT.html) aren't supported and can cause data discrepancy in case of a rollback.\n- Database Migration Service replicates user-defined data types, but only stores the base data type from which you derive your user-defined types. For example, if you define a `USERNAME` data type based on the `VARCHAR2` data type, the data is stored in the destination as `VARCHAR`.\n\nDatabase, transactions and data consistency\n-------------------------------------------\n\n- The migration is eventually consistent, as Database Migration Service doesn't replicate each transaction as it happens. The migration brings in data from multiple tables. The order in which data is loaded into the destination may vary, but re-aligns with the source after writes on the source are stopped and the migration buffer is cleared.\n- For heterogeneous Oracle migrations, Database Migration Service can only migrate one database per migration job.\n- Database Migration Service supports Oracle multi-tenant architecture (CDB/PDB), but you can only migrate a single pluggable database per migration job.\n- Oracle Label Security (OLS) isn't replicated.\n- The destination database must have the same name as the username that's used to connect to the database.\n- Any transactions that are rolled back in your source database during the migration process might be visible in the destination temporarily (when the transaction is long enough).\n- Database Migration Service doesn't support direct connectivity to databases using the Single Client Access Name (SCAN) feature in Oracle Real Application Clusters (RAC) environments. For potential solutions to using public IP allowlist connectivity with such environments, see [Troubleshoot Oracle SCAN errors](/database-migration/docs/oracle-to-alloydb/diagnose-issues#troubleshoot-scan).\n\nData encoding\n-------------\n\n- Database Migration Service supports only `UTF8` set encodings for the destination database. Schema and table names that include characters which aren't part of the `UTF8` encoding set are not supported.\n- Database Migration Service supports the following character set encodings for Oracle databases:\n - `AL16UTF16`\n - `AL32UTF8`\n - `IN8ISCII`\n - `IW8ISO8859P8`\n - `JA16SJIS`\n - `JA16SJISTILDE`\n - `KO16MSWIN949`\n - `US7ASCII`\n - `UTF8`\n - `WE8ISO8859P1`\n - `WE8ISO8859P9`\n - `WE8ISO8859P15`\n - `WE8MSWIN1252`\n - `ZHT16BIG5`\n\nTables, schemas, and other objects\n----------------------------------\n\n- During a migration, data definition language (DDL) changes to data, schemas, and metadata aren't supported. If you update your schema during the migration, you need to pull the changes to your conversion workspace, convert the code, clean your destination and run the migration job again.\n- Table column names that include characters other than alphanumeric characters or an underscore (`_`) aren't supported.\n- Maximum name length for tables or columns is 30 characters. Database Migration Service can't replicate tables that exceed this limit, or tables that contain columns whose names exceed this limit.\n- Index-organized tables (IOTs) aren't supported.\n- Global temporary tables require the `pgtt` PostgreSQL extension installed and created on the destination.\n- For columns of type `BFILE`, only the path to the file will be replicated. The contents of the file won't be replicated.\n- For Oracle 11g, tables that have columns of data types `ANYDATA` or `UDT` aren't supported, and the entire table won't be replicated.\n- Jobs that are scheduled by using [`dbms_job`](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_JOB.html) or [`dbms_scheduler`](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_SCHEDULER.html) aren't migrated.\n- Materialized views definitions are migrated, but their materialized data isn't. After you finish migrating, refresh your materialized views in order to populate them with data from the migrated tables.\n- Sequence values are migrated, but their values in the source database might keep advancing before the migration is completed. After complete the migration, update the sequence values on the destination instance to match those in the source database.\n- Migration jobs are limited to 10,000 tables.\n- Rows have a size limitation of 100 MB. Rows that exceed the 100 MB limit are not migrated, and show up as errors in the migration job.\n- Any tables that are created after the migration has started aren't be migrated automatically. First, you need to pull their schema in the conversion workspace, apply converted definitions to the destination, and update the migration job.\n\n### Data type limitations\n\nThe following data types are unsupported for Oracle migrations:\n\n- `ANYDATA` (For Oracle 11g, tables with `ANYDATA` are completely unsupported and not replicated.)\n- `BFILE`\n- `INTERVAL DAY TO SECOND`\n- `INTERVAL YEAR TO MONTH`\n- `LONG/LONG RAW`\n- `SDO_GEOMETRY`\n- `UDT`\n- `UROWID`\n- `XMLTYPE`\n- **Zero dates** in `TIMESTAMP`\n\n### Considerations for primary keys\n\nTables without primary keys don't promise consistent replication.\nDatabase Migration Service migrates only tables that have primary keys.\nIf your source database includes tables that don't have primary keys,\nDatabase Migration Service conversion workspaces automatically create any missing\nprimary keys in the destination tables when you\n[convert your source code and schema](/database-migration/docs/oracle-to-alloydb/convert-sql).\n\nIf you use legacy conversion workspaces, you need to manually create primary\nkey constraints in the converted tables in the destination database before\nyou start the migration. For more information, see\n[Legacy conversion workspaces](/database-migration/docs/oracle-to-alloydb/legacy-conversion-workspaces).\n\n### Considerations for foreign keys and triggers\n\nForeign keys and triggers present in your source database might lead to\ndata integrity issues, or even cause the migration job to fail.\nYou can prevent these issues if you skip foreign keys and triggers\n[by using the `REPLICATION` option for the migration user](/database-migration/docs/oracle-to-alloydb/configure-your-destination-postgresql-database).\nAlternatively, you can also drop all foreign keys and triggers in the destination\ndatabase and re-create them when the migration is complete.\n\n#### Triggers\n\nData replicated by Database Migration Service already incorporates any changes made by\ntriggers on the source database. If triggers are enabled on the destination,\nthey can fire again and potentially manipulate data, resulting in data integrity\nor duplication issues.\n\n#### Foreign keys\n\nDatabase Migration Service doesn't replicate data in a transactional\nmanner, so tables might be migrated out of order. If foreign keys are present,\nand a child table that uses a foreign key is migrated before its parent, you might\nencounter replication errors.\n\nRecommendations\n---------------\n\n- When you [create your destination Cloud SQL database](/database-migration/docs/oracle-to-alloydb/configure-your-destination-postgresql-database), make sure that you use enough compute and memory resources to cover your migration needs. We recommend a machine type with at least a dual-core CPU.\n\n For example, if your machine name is `db-custom`, and it has\n 2 CPUs and 3840 MB of RAM, then the format for the machine type name\n is `db-custom-2-3840`.\n- The destination Cloud SQL database is writable during the migration to allow Data Manipulation Language (DML) changes to be applied if needed. Take care not to make any changes to the database configuration or table structures which might break the migration process or impact data integrity.\n\nQuotas\n------\n\n- Up to 2,000 connection profiles and 1,000 migration jobs can exist at any given time. To create space for more, migration jobs (including completed ones) and connection profiles can be deleted."]]
