Limites et recommandations connues

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 en tant que 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é.
  • 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é de la liste d'autorisation des 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
    • 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 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 celles 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 jobs planifiés à l'aide de dbms_job ou dbms_scheduler ne sont pas migrés.
  • 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 sur 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).