Limites et recommandations connues

Cette page décrit les limites connues (y compris les considérations spéciales pour la gestion d'entités telles que les clés primaires ou les clés étrangères et les 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 un job de migration actif ne sont pas automatiquement migrées. Si vous modifiez votre schéma pendant la migration, vous devez d'abord mettre à jour l'espace de travail de conversion avec les modifications du 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 au fur et à mesure qu'elle se produit. La migration apporte des données provenant de plusieurs tables. L'ordre dans lequel les données sont chargées dans la destination peut varier, mais il est réaligné sur la source une fois que les écritures sur la source sont arrêtées et que le tampon de migration est vidé.
  • Pour les migrations Oracle hétérogènes, Database Migration Service ne peut migrer qu'une seule base de données par job de migration.
  • Database Migration Service est compatible avec l'architecture mutualisée d'Oracle (CDB/PDB), mais vous ne pouvez migrer qu'une seule base de données connectable par job 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 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é SCAN (Single Client Access Name) dans les environnements Oracle Real Application Clusters (RAC). Pour trouver des solutions potentielles à l'utilisation de la connectivité par liste d'autorisation d'adresses IP publiques avec de tels environnements, consultez Résoudre les erreurs Oracle SCAN.

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é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 apportées aux données, aux schémas et aux métadonnées en langage de définition de données (LDD) 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 le job de migration.
  • Les noms de colonnes de table 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 du nom des tables ou des 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 le nom dépasse cette limite.
  • Les tables organisées par index (IOT) ne sont pas compatibles.
  • Les tables temporaires globales nécessitent l'installation et la création de l'extension PostgreSQL pgtt 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 comportant des colonnes de types de données ANYDATA ou UDT ne sont pas compatibles, 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 jobs de migration sont limités à 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 comme des erreurs dans le job 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.
  • Les tables sources qui contiennent des colonnes binaires et n'ont pas de clés primaires ne sont pas compatibles avec la migration de données dans les migrations continues.
  • Les colonnes virtuelles (GENERATED ALWAYS AS (...) VIRTUAL) ne sont pas répliquées lors de la migration des données, car Oracle n'écrit pas les valeurs des colonnes virtuelles dans les journaux de rétablissement. Si une colonne virtuelle fait partie d'une clé primaire composite, seules les colonnes non virtuelles sont utilisées comme clé primaire lors de la réplication.

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 nulles dans TIMESTAMP

Remarques 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 possèdent des clés primaires. 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. Ce processus automatisé nécessite que vos tables sources :

  • ne disposent pas déjà de clés primaires ;
  • Ne définissez pas de contrainte UNIQUE sans colonnes pouvant accepter une valeur nulle.
  • Ne créez pas d'index UNIQUE sans colonnes pouvant accepter une valeur nulle.

Si vos tables ne répondent pas à ces exigences, vous devez ajouter manuellement les clés primaires manquantes aux tables du schéma PostgreSQL converti. Vous pouvez également désactiver la génération automatique de clés primaires avec la directive de conversion GENERATE_MISSING_PK.

Pour les migrations continues : les tables sources contenant des colonnes binaires et ne disposant pas de clés primaires ne sont pas compatibles avec la migration de données dans les migrations continues.

Si vous utilisez des espaces de travail de conversion anciens, 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 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 l'échec du job de migration. Vous pouvez éviter ces problèmes en ignorant les clés étrangères et les déclencheurs à l'aide de 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 sur 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é des données ou de duplication.

Clés étrangères

Database Migration Service ne réplique pas les données de manière transactionnelle. Les tables peuvent donc être migrées dans le désordre. Si des clés étrangères sont présentes et qu'une table enfant utilisant 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 couvrir 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 de 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 la structure des tables, car cela pourrait perturber le processus de migration ou affecter l'intégrité des données.

Quotas

  • Vous pouvez avoir jusqu'à 2 000 profils de connexion et 1 000 jobs de migration à tout moment. Pour libérer de l'espace, vous pouvez supprimer des jobs de migration (y compris ceux qui sont terminés) et des profils de connexion.