Documentation Oracle Cloud Infrastructure

Dépannage du service Oracle NoSQL Database Migrator

Apprenez-en davantage sur les défis généraux auxquels vous êtes confronté lors de l’utilisation du , et sur la manière de les résoudre.

Echec de la migration. Comment résoudre ce problème ?

L'échec de la migration des données peut être dû à plusieurs raisons sous-jacentes. Les causes importantes sont répertoriées ci-dessous :

Tableau 9-3 Causes d'échec de migration

Message d'erreur Description Résolution
Failed to connect to Oracle NoSQL Database Le programme de migration n'a pas pu établir de connexion avec la base de données NoSQL.
  • Vérifiez si les valeurs des attributs storeName et helperHosts du fichier JSON de configuration sont valides et que les hôtes sont accessibles.
  • Pour un emplacement de stockage sécurisé, vérifiez que le fichier de sécurité est valide avec les valeurs de nom utilisateur et de mot de passe correctes.
Failed to connect to Oracle NoSQL Database Cloud Service Le programme de migration n'a pas pu établir de connexion avec Oracle NoSQL Database Cloud Service.
  • Vérifiez si l'URL endpoint ou le nom de région indiqué dans le fichier JSON de configuration est correct.
  • Vérifiez si le fichier d'informations d'identification OCI est disponible dans le chemin indiqué dans le fichier JSON de configuration.
  • Assurez-vous que les informations d'identification OCI fournies dans les informations d'identification OCI sont valides.
Table not found La table identifiée pour la migration n'a pas pu être localisée par NoSQL Database Migrator.

Pour la source :

  • Vérifiez si la table est présente dans la base de données source.
  • Assurez-vous que la table est qualifiée avec son espace de noms dans le fichier JSON de configuration, si elle est créée dans un espace de noms autre que par défaut.
  • Vérifiez si vous disposez de l'autorisation de lecture/écriture requise pour accéder à la table.
  • Si la source est Oracle NoSQL Database Cloud Service, vérifiez si le nom de compartiment valide est indiqué dans le fichier JSON de configuration et assurez-vous que vous disposez de l'autorisation requise pour accéder à la table.

Pour le dissipateur :

  • Vérifiez si la table est présente dans l'évier. S'il n'existe pas, vous devez créer la table manuellement ou utiliser la configuration schemaInfo pour la créer via la migration.
DDL Execution failed Les commandes DDL fournies dans le fichier de définition de schéma d'entrée ne sont pas valides.
  • Vérifiez la syntaxe des commandes DDL dans le fichier schemaPath.
  • Vérifiez qu'il n'existe qu'une seule instruction DDL par ligne dans le fichier schemaPath.
failed to write record to the sink table with java.lang.IllegalArgumentException L'enregistrement d'entrée ne correspond pas au schéma de table de l'évier.
  • Vérifiez si les types de données et les noms de colonne indiqués dans la table de dissipation d'adresse cible correspondent au schéma de la table de dissipation d'adresse.
  • Si vous avez appliqué une transformation, vérifiez si les enregistrements transformés correspondent au schéma de la table des sink.
Request timeout L'opération de la source ou du puits n'a pas été terminée dans les temps prévus.
  • Vérifiez la connexion réseau.
  • Vérifiez que la base de données NoSQL est en fonctionnement.
  • Essayez d'augmenter la valeur requestTimeout dans le fichier JSON de configuration.

Que dois-je prendre en compte avant le redémarrage d'une migration en échec ?

Lorsqu'une tâche de migration de données échoue, le dissipateur de données se trouve dans un état intermédiaire contenant les données importées jusqu'au point d'échec. Vous pouvez identifier les détails de l'erreur et de l'échec à partir des journaux et redémarrer la migration après avoir diagnostiqué et corrigé l'erreur. Une migration redémarrée commence, traitant toutes les données depuis le début. Il n'existe aucun moyen de vérifier et de redémarrer la migration à partir du point de défaillance. Par conséquent, NoSQL Database Migrator écrase tout enregistrement qui a déjà été migré vers le dissipateur.

La migration est trop lente. Comment l’accélérer ?

Le temps nécessaire à la migration des données dépend de plusieurs facteurs tels que le volume des données migrées, la vitesse du réseau et la charge actuelle sur la base de données. Dans le cas d'un service cloud, la vitesse de migration dépend également du débit de lecture et du débit d'écriture provisionnés. Ainsi, pour améliorer la vitesse de migration, vous pouvez :
  • Essayez de réduire la charge globale actuelle d'Oracle NoSQL Database lors de la migration des données.
  • Assurez-vous que la machine qui exécute la migration, la source et l'évier se trouvent dans le même centre de données et que les temps d'attente réseau sont minimes.
  • Dans le cas d'Oracle NoSQL Database Cloud Service, provisionnez un débit de lecture/écriture élevé et vérifiez si le stockage alloué pour la table est suffisant ou non. Si NoSQL Database Migrator ne crée pas la table, vous pouvez augmenter le débit d'écriture. Si le programme de migration crée la table, envisagez de spécifier une valeur plus élevée pour le paramètre schemaInfo.writeUnits dans la configuration de l'évier. Une fois la migration de données terminée, vous pouvez réduire cette valeur. Tenez compte des limites quotidiennes concernant les modifications de débit. Reportez-vous à Limites cloud et à Modèles de configuration de lien.

J’ai une migration à long terme impliquant des ensembles de données volumineux. Comment suivre la progression de la migration ?

Vous pouvez activer la journalisation supplémentaire pour suivre la progression d'une migration à longue durée d'exécution. Pour contrôler le comportement de journalisation d'Oracle NoSQL Database Migrator, vous devez définir le niveau de connexion souhaité dans le fichier logging.properties. Ce fichier est fourni avec le package NoSQL Database Migrator et disponible dans le répertoire où Oracle NoSQL Database Migrator a été décompressé. Les différents niveaux de journalisation sont OFF, SEVERE, WARNING, INFO, FINE, et ALL dans l'ordre de la verbosité croissante. La définition du niveau de journalisation sur OFF désactive toutes les informations de journalisation, tandis que la définition du niveau de journalisation sur ALL fournit les informations de journalisation complètes. Le niveau de journalisation par défaut est WARNING. Toutes les sorties de journalisation sont configurées pour accéder à la console par défaut. Vous pouvez voir des commentaires dans le fichier logging.properties pour connaître chaque niveau de journal.