Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Cette page décrit les limites connues (y compris les considérations spéciales pour la gestion des entités telles que les
clés primaires ou les
clés étrangères et les déclencheurs), ainsi que les
bonnes pratiques pour les migrations Oracle hétérogènes avec Database Migration Service.
Éléments non migrés
Les utilisateurs et les autorisations ne sont pas migrés.
Les modifications de schéma qui se produisent pendant une tâche de migration active ne sont pas migrées automatiquement. Si vous modifiez votre schéma pendant la migration, vous devez d'abord mettre à jour l'espace de travail de conversion avec les modifications apportées au schéma, puis actualiser les jobs de migration concernés. Pour en savoir plus, consultez
Ajouter un schéma ou des tables mis à jour au job de migration.
Les instructions SAVEPOINT ne sont pas compatibles et peuvent entraîner des écarts de données en cas de rollback.
Database Migration Service réplique les types de données définis par l'utilisateur, mais ne stocke que le type de données de base à partir duquel vous dérivez vos types définis par l'utilisateur.
Par exemple, si vous définissez un type de données USERNAME basé sur le type de données VARCHAR2, les données sont stockées dans la destination au format VARCHAR.
Base de données, transactions et cohérence des données
La migration est cohérente à terme, car Database Migration Service ne réplique pas chaque transaction en temps réel. La migration importe les données de plusieurs tables. L'ordre dans lequel les données sont chargées dans la destination peut varier, mais il se réaligne sur la source une fois que les écritures sur la source sont arrêtées et que le tampon de migration est effacé.
Pour les migrations Oracle hétérogènes, Database Migration Service ne peut migrer qu'une seule base de données par tâche de migration.
Database Migration Service est compatible avec l'architecture mutualisée Oracle (CDB/PDB), mais vous ne pouvez migrer qu'une seule base de données connectable par tâche de migration.
Oracle Label Security (OLS) n'est pas répliqué.
La base de données de destination doit porter le même nom que le nom d'utilisateur utilisé pour se connecter à la base de données.
Toutes les transactions annulées dans votre base de données source pendant le processus de migration peuvent être visibles temporairement dans la destination (lorsque la transaction est suffisamment longue).
Database Migration Service n'est pas compatible avec la connectivité directe aux bases de données à l'aide de la fonctionnalité SCAN (Single Client Access Name) dans les environnements Oracle Real Application Clusters (RAC). Pour trouver des solutions potentielles à l'utilisation de la connectivité avec liste d'autorisation d'adresses IP publiques avec de tels environnements, consultez
Résoudre les erreurs SCAN Oracle.
Codage des données
Database Migration Service n'accepte que les encodages UTF8 pour la base de données de destination. Les noms de schémas et de tables qui incluent des caractères ne faisant pas partie de l'ensemble d'encodage UTF8 ne sont pas acceptés.
Database Migration Service est compatible avec les encodages de jeu de caractères suivants pour les bases de données Oracle :
AL16UTF16
AL32UTF8
IN8ISCII
IW8ISO8859P8
JA16SJIS
JA16SJISTILDE
KO16MSWIN949
US7ASCII
UTF8
WE8ISO8859P1
WE8ISO8859P9
WE8ISO8859P15
WE8MSWIN1252
ZHT16BIG5
Tables, schémas et autres objets
Lors d'une migration, les modifications LDD (langage de définition de données) apportées aux données, aux schémas et aux métadonnées ne sont pas acceptées. Si vous mettez à jour votre schéma pendant la migration, vous devez extraire les modifications vers votre espace de travail de conversion, convertir le code, nettoyer votre destination et exécuter à nouveau le job de migration.
Les noms de colonnes de tableau qui incluent des caractères autres que des caractères alphanumériques ou un trait de soulignement (_) ne sont pas acceptés.
La longueur maximale des noms de tables ou de colonnes est de 30 caractères.
Database Migration Service ne peut pas répliquer les tables qui dépassent cette limite, ni les tables qui contiennent des colonnes dont le nom dépasse cette limite.
Les tables organisées en index (IOT) ne sont pas acceptées.
Les tables temporaires globales nécessitent que l'extension PostgreSQL pgtt soit installée et créée sur la destination.
Pour les colonnes de type BFILE, seul le chemin d'accès au fichier sera répliqué. Le contenu du fichier ne sera pas répliqué.
Pour Oracle 11g, les tables dont les colonnes contiennent les types de données ANYDATA ou UDT ne sont pas acceptées, et l'intégralité de la table ne sera pas répliquée.
Les définitions des vues matérialisées sont migrées, mais pas leurs données matérialisées. Une fois la migration terminée, actualisez vos vues matérialisées pour les remplir avec les données des tables migrées.
Les valeurs de séquence sont migrées, mais leurs valeurs dans la base de données source peuvent continuer à progresser avant la fin de la migration. Une fois la migration terminée, mettez à jour les valeurs de séquence sur l'instance de destination pour qu'elles correspondent à celles de la base de données source.
Les tâches de migration sont limitées à 10 000 tables.
La taille des lignes est limitée à 100 Mo. Les lignes qui dépassent la limite de 100 Mo ne sont pas migrées et apparaissent comme des erreurs dans la tâche de migration.
Les tables créées après le début de la migration ne sont pas migrées automatiquement. Vous devez d'abord extraire leur schéma dans l'espace de travail de conversion, appliquer les définitions converties à la destination et mettre à jour le job de migration.
Limites des types de données
Les types de données suivants ne sont pas acceptés pour les migrations Oracle :
ANYDATA (Pour Oracle 11g, les tables avec ANYDATA ne sont pas du tout compatibles et ne sont pas répliquées.)
BFILE
INTERVAL DAY TO SECOND
INTERVAL YEAR TO MONTH
LONG/LONG RAW
SDO_GEOMETRY
UDT
UROWID
XMLTYPE
Aucune date dans TIMESTAMP
Points à prendre en compte pour les clés primaires
Les tables sans clé primaire ne garantissent pas une réplication cohérente.
Database Migration Service ne migre que les tables disposant d'une clé primaire.
Si votre base de données source inclut des tables sans clé primaire, les espaces de travail de conversion Database Migration Service créent automatiquement les clés primaires manquantes dans les tables de destination lorsque vous
convertissez votre code source et votre schéma.
Si vous utilisez les anciens espaces de travail de conversion, vous devez créer manuellement des contraintes de clé primaire dans les tables converties de la base de données de destination avant de lancer la migration. Pour en savoir plus, consultez
Anciens espaces de travail de conversion.
Remarques importantes concernant les clés étrangères et les déclencheurs
Les clés étrangères et les déclencheurs présents dans votre base de données source peuvent entraîner des problèmes d'intégrité des données, voire faire échouer le job de migration.
Vous pouvez éviter ces problèmes en ignorant les clés étrangères et les déclencheurs
en utilisant l'option REPLICATION pour l'utilisateur de la migration.
Vous pouvez également supprimer toutes les clés étrangères et tous les déclencheurs dans la base de données de destination, puis les recréer une fois la migration terminée.
Déclencheurs
Les données répliquées par Database Migration Service intègrent déjà toutes les modifications apportées par les déclencheurs de la base de données source. Si des déclencheurs sont activés dans la destination, ils peuvent se déclencher à nouveau et potentiellement manipuler les données, ce qui peut entraîner des problèmes d'intégrité ou de duplication des données.
Clés étrangères
Database Migration Service ne réplique pas les données de manière transactionnelle. Il est donc possible que les tables soient migrées dans le désordre. Si des clés étrangères sont présentes et qu'une table enfant qui utilise une clé étrangère est migrée avant son parent, vous risquez de rencontrer des erreurs de réplication.
Recommandations
Lorsque vous
créez votre base de données Cloud SQL de destination, assurez-vous d'utiliser suffisamment de ressources de calcul et de mémoire pour répondre à vos besoins de migration. Nous vous recommandons d'utiliser un type de machine avec au moins un CPU double cœur.
Par exemple, si votre machine est nommée db-custom et qu'elle dispose de deux processeurs et de 3 840 Mo de RAM, le nom du type de machine est au format db-custom-2-3840.
La base de données Cloud SQL de destination est accessible en écriture pendant la migration pour permettre l'application des modifications du langage de manipulation de données (LMD) si nécessaire.
Veillez à ne pas modifier la configuration de la base de données ni les structures de table, car cela pourrait perturber le processus de migration ou affecter l'intégrité des données.
Quotas
Jusqu'à 2 000 profils de connexion et 1 000 tâches de migration peuvent coexister à un moment donné. Pour libérer de l'espace, vous pouvez supprimer des profils de connexion et des tâches de migration (y compris celles déjà effectuées).
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/05 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/05 (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."]]
