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 une tâche de migration active 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 de schéma, puis actualiser les tâches de migration concernées. Pour en savoir plus, consultez 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 incohérences de données en cas de restauration.
  • 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 VARCHAR2 type de données, 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. 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 s'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 qui sont restauré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 connaître les solutions potentielles permettant d'utiliser la connectivité de liste d'autorisation d'adresse IP publique avec de tels environnements, consultez Résoudre les erreurs SCAN Oracle.

Codage des données

  • Database Migration Service n'est compatible qu'avec les encodages de l'ensemble 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 compatibles.
  • 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

  • Pendant 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 compatibles. 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 table qui incluent des caractères autres que des caractères alphanumériques caractères ou un trait de soulignement (_) ne sont pas compatibles.
  • 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 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 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 contenant des colonnes de types de données ANYDATA ou UDT ne sont pas compatibles, et la table entière ne sera pas répliquée.
  • Les tâches planifiées à l'aide de dbms_job ou dbms_scheduler ne sont pas migrées.
  • Les définitions de vues matérialisées sont migrées, mais pas leurs données matérialisées n'est pas. 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 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 la tâche de migration.
  • Les tables sources qui contiennent des colonnes binaires et ne possèdent pas de clés primaires ne sont pas compatibles avec la migration de données dans les migrations continues.

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

Considérations relatives aux clés primaires

Les tables sans clé primaire ne garantissent pas une réplication cohérente. Database Migration Service ne migre que les tables possédant une clé primaire. Si votre base de données source inclut des tables sans clé primaire, les espaces de travail de conversion de 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. Vous pouvez également désactiver la génération automatique de clés primaires à l'aide de la directive de conversion GENERATE_MISSING_PK.

Pour les migrations continues : les tables sources qui contiennent des colonnes binaires et ne possèdent 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 hérités, vous devez créer manuellement des contraintes de clé primaire dans les tables converties de la base de données de destination avant de commencer la migration. Pour en savoir plus, consultez Espaces de travail de conversion hérités.

Considérations relatives aux clés étrangères et aux 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 de la tâche 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 et 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 les déclencheurs sont activés sur la destination, ils peuvent se déclencher à nouveau et potentiellement manipuler les données, ce qui entraîne 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 qui utilise une clé étrangère est migrée avant son parent, des erreurs de réplication peuvent se produire.

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 se nomme db-custom, et qu'elle dispose de deux CPU et 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 LMD (langage de manipulation de données) si nécessaire. Veillez à n'apporter aucune modification à la configuration de la base de données ni aux structures de table qui pourraient 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, supprimez des profils de connexion et des tâches de migration (y compris celles déjà effectuées) .