Limites et recommandations connues

Cette page décrit les limites connues (y compris des considérations spéciales pour la gestion d'entités telles que les clés primaires ou les clés étrangères et déclencheurs), ainsi que les pratiques recommandées 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 tâches de migration concernées. Pour en savoir plus, consultez la section Ajouter un schéma ou des tables mis à jour à la tâche de migration.
  • Les instructions SAVEPOINT ne sont pas compatibles et peuvent entraîner des différences 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 en tant que VARCHAR.

Base de données, transactions et cohérence des données

  • La migration est finalement cohérente, car Database Migration Service ne réplique pas chaque transaction au fur et à mesure. La migration importe des 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 avec la source une fois les écritures sur la source arrêtées et le tampon de migration 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 multi-tenant d'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 s'y connecter.
  • Toutes les transactions annulées dans votre base de données source pendant le processus de migration peuvent être temporairement visibles 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é de nom d'accès client unique (SCAN) dans les environnements Oracle Real Application Clusters (RAC). Pour trouver des solutions potentielles à l'utilisation de la connectivité de liste d'autorisation d'adresses IP publiques avec de tels environnements, consultez la page Résoudre les erreurs SCAN Oracle.

Codage des données

  • Database Migration Service n'accepte que les encodages définis par UTF8 pour la base de données de destination. Les noms de schéma et de table qui incluent des caractères qui ne font 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
    • JA16SJIS
    • 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 dans votre espace de travail de conversion, convertir le code, nettoyer votre destination et exécuter à nouveau la tâche 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 contenant des colonnes dont les noms dépassent cette limite.
  • Les tables organisées en index (IOT) ne sont pas compatibles.
  • Les tables temporaires globales nécessitent que l'extension PostgreSQL pgtt soit installée et créée à 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 contenant des colonnes de types de données ANYDATA ou UDT ne sont pas acceptées, et l'ensemble de la table ne sera pas répliqué.
  • Les tâches planifiées à l'aide de dbms_job ou de dbms_scheduler ne sont pas migrées.
  • 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 afin de 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 s'affichent sous forme d'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. Tout d'abord, vous devez extraire son schéma dans l'espace de travail de conversion, appliquer les définitions converties à la destination et mettre à jour la tâche de migration.

Limites des types de données

Les types de données suivants ne sont pas compatibles avec 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
  • Dates "zéro" dans TIMESTAMP

Remarques importantes concernant 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 qui ont 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 d'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 la section Anciens espaces de travail de conversion.

Considérations 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 ou même faire échouer la tâche de migration. Pour éviter ces problèmes, ignorez les clés étrangères et les déclencheurs en utilisant l'option REPLICATION pour l'utilisateur de migration. Vous pouvez également supprimer toutes les clés étrangères et tous les déclencheurs de 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 dans la base de données source. Si des déclencheurs sont activés sur la destination, ils peuvent se déclencher à nouveau et potentiellement manipuler des 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 sa table parente, 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 le nom de votre machine est db-custom et qu'elle dispose de deux processeurs et de 3 840 Mo de RAM, le format du nom du type de machine est 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 risque de perturber le processus de migration ou d'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).