Résoudre les problèmes de performances des jeux d’importation
Examinez ces problèmes de performances pour résoudre les problèmes et améliorer les performances de vos tâches de jeu d’importation.
Exécution des règles métier pendant la transformation
L’exécution de règles métier pendant la transformation peut entraîner une transformation plus longue que prévu ou un ralentissement de l’instance.
Devient un problème : lors de l’importation d’une très grande quantité de données. Par exemple, l’importation de toutes les données d’un ancien système.
Symptômes :La transformation prend beaucoup plus de temps que prévu. En outre, l’instance entière peut être lente pendant cette période.
Scripts de transformation lente
L’utilisation de plusieurs requêtes GlideRecord ou de grandes boucles peut ralentir les scripts de transformation.
Devient un problème : lorsque les scripts de transformation utilisent plusieurs requêtes GlideRecord ou parcourent de grandes collections d’objets pour chaque ligne. Ce problème peut se produire lorsque le script de transformation n’est pas efficace. Dans la plupart des cas, les objectifs de script peuvent être atteints à l’aide de la fonctionnalité intégrée à l’application Jeu d’importation. Par exemple, vous pouvez scripter la fusion sensible à la casse au lieu d’écrire des scripts qui utilisent des requêtes GlideRecord. Les requêtes GlideRecord ralentissent généralement l’importation.
Symptômes : La transformation prend beaucoup plus de temps que prévu. Selon le script, l’instance entière peut être lente pendant cette période.
Comment éviter cela : utilisez les fonctionnalités du système de base dans la mesure du possible au lieu d’écrire des scripts personnalisés et, si vous écrivez des scripts, évitez d’écrire des scripts compliqués qui utilisent des requêtes GlideRecord.
Importation de données qui n’ont pas changé
L’importation répétée de données qui n’ont pas changé entraîne de nombreuses lignes ignorées.
Devient un problème : lorsque vous importez des données à partir d’une table très volumineuse et que la plupart des enregistrements ne sont pas mis à jour régulièrement.
Symptômes : Le jeu d’importation prend plus de temps que prévu. Sous , attendez-vous à voir une importation avec un nombre total très élevé avec un nombre Ignoré qui est également très élevé - ceci se trouve sous la colonne Message . Ce qui indique que la plupart des enregistrements importés n’ont pas réellement changé. Ces enregistrements n’avaient pas besoin d’être importés.
Comment éviter cela : si vous exécutez une importation JDBC, utilisez l’option Date/heure de la dernière exécution dans votre source de données de jeu d’importation. Pour un type d’importation de fichier, assurez-vous que ce qui génère vos fichiers ne fait qu’ajouter des données nouvelles ou qui ont été modifiées.
Coalescence sur des champs non indexés
La coalescence sur des champs non indexés avec une grande quantité de données peut entraîner un ralentissement des transformations.
Devient un problème : lors de la mise en correspondance sur des champs qui ne sont pas indexés, l’étape de transformation d’une importation ralentit. Cependant, cela ne devient un problème que s’il y a une quantité suffisante de données. Dans les cas extrêmes, cela entraîne des problèmes de performances de la base de données en raison d’une charge supplémentaire.
Symptômes : le temps passé dans l’étape de transformation de l’importation est important par rapport au temps nécessaire au chargement des données. Attendez-vous à des temps de transformation élevés.
Comment éviter cela : Si possible, vous devez regrouper un champ unique et déjà indexé. Pour déterminer si un champ est déjà indexé, accédez à et trouvez la table. Dans la liste des colonnes de cette table, une colonne indexée comporte une icône bleue avec un i à côté si elle est indexée. Pour obtenir de l’aide sur l’indexation d’un champ, contactez ServiceNow le support technique.
Exécution simultanée des importations
L’exécution simultanée d’importations peut entraîner une charge excessive de la base de données.
Devient un problème : lorsque l’importation de grandes quantités de données entraîne une charge supplémentaire sur la base de données. Par exemple, l’importation simultanée de 500 000 utilisateurs et de 200 000 éléments de configuration. Cela peut avoir un impact significatif sur les performances de toutes les requêtes sur le système en raison de l’augmentation de la charge sur la base de données. Ce problème est particulièrement grave lorsque deux importations sont importées dans la même table. Dans un tel cas, il y a un problème de contentieux possible pour la table. De plus, selon la table impliquée dans le traitement, cela peut gravement dégrader les performances de l’importation et de l’instance.
Symptômes : Plusieurs importations simultanées en cours d’exécution lentes combinées à la charge sur la base de données. Vous voyez un grand nombre d’insertions et de mises à jour ; et s’il y a suffisamment de charge ou de contention, des temps d’attente d’E/S élevés.
Comment éviter cela : échelonnez vos importations afin qu’elles ne se chevauchent pas.
Tables de jeux d’importation volumineuses
Si vous ne nettoyez pas les tables de jeu d’importation, celles-ci risquent d’être encombrées et lentes.
Devient un problème : lorsque la tâche de suppression de jeu d’importation n’est pas en cours d’exécution.
Symptômes : Il s’agit d’un problème de taille. Si les jeux d’importation ne sont pas nettoyés régulièrement (un nettoyage est recommandé après sept jours de données), le tableau se remplit, ce qui entraîne l’arrêt des importations.
Comment éviter cela : vérifiez que la tâche Supprimer les ensembles de données à importer est en cours d’exécution. S’il n’est pas en cours d’exécution, contactez-nous Service et assistance client , car ils tronqueront toutes les tables de jeux d’importation avant d’activer cette tâche.
Modification du schéma de table pendant l’importation
La modification du schéma de table, par exemple l’importation d’une nouvelle colonne, verrouille la table de jeux d’importation.
Devient un problème : chaque fois qu’une nouvelle colonne est importée, l’intégralité de la table de jeux d’importation est verrouillée pendant ce changement de schéma et, en fonction de la taille de la table, cela peut prendre entre cinq et dix minutes. Pendant ce temps, aucune donnée ne peut être sélectionnée ou insérée. Si cette table n’est pas utilisée souvent, cela peut ne pas poser de problèmes. Toutefois, si cette table est fréquemment utilisée, par exemple la table d’importation LDAP, des problèmes peuvent survenir.
Symptômes : Les symptômes de ce problème peuvent varier. Dans notre exemple de table d’importation LDAP, toutes les transactions nécessitant une requête de la table d’importation LDAP devront attendre la fin du changement de schéma.
Comment éviter cela : tronquez la table d’importation avant d’importer avec une nouvelle colonne.
Importation de très grands ensembles de données
L’importation d’un très grand ensemble de données prend plus de temps que l’importation de plusieurs jeux de données plus petits.
Devient un problème : lorsque de très grands ensembles de données sont importés dans une seule tâche.
Symptômes : La tâche d’importation prend beaucoup de temps.
Comment éviter cela : divisez un ensemble de données très volumineux en plusieurs tâches plus petites pour obtenir des résultats plus rapides. Prendre en compte les ensembles d’importation de moins de 100 000 enregistrements à titre indicatif. Par exemple, l’importation de 10 ensembles de 100 000 enregistrements se termine plus rapidement qu’une importation de 1 million d’enregistrements, même si le total des données importées est le même.
Importations de données volumineuses avec de nombreux champs de référence
L’importation d’un volume élevé de données comportant de nombreuses références à résoudre peut prendre plus de temps que prévu ou ralentir la base de données.
Devient un problème : lors de l’utilisation d’une carte de transformation pour les importations de gros volumes de données avec de nombreux champs de référence.
Symptômes : La transformation prend beaucoup plus de temps que prévu. Lors de l’importation, l’ensemble de la base de données ralentit.
Comment éviter cela : utilisez le stockage secondaire pour rechercher des références. Le stockage secondaire utilise une base de données secondaire pour la résolution de référence. Il permet de rediriger certaines requêtes de lecture vers la base de données secondaire, ce qui réduit la charge sur la base de données primaire.
- Activez le module d’extension Secondary Database Pools [com.glide.secondary_db_pools]. Pour plus d'informations, consultez Request a plugin.
- Confirmer que la catégorie import_reference_resoultion de la table Catégories de base de données secondaires [sys_db_category] a été configurée et activée. Lorsque vous demandez le module d’extension, ServiceNow le support configure cette catégorie pour vous.
Une fois que le module d’extension est activé et que votre catégorie de stockage secondaire a été configurée et activée, une case à cocher Utiliser le stockage secondaire pour les références s’affiche dans le formulaire pour Créer une carte de transformation. Utilisez cette case à cocher pour activer ou désactiver le stockage secondaire.
Lors de l’utilisation du stockage secondaire, définissez le champ d’action Choix dans la carte de champs sur ignorer ou rejeter. Si vous définissez l’action Choix sur créer , plusieurs copies d’un enregistrement peuvent être créées, car la résolution de référence ne détecte pas immédiatement les enregistrements nouvellement créés. Pour plus d’informations sur les actions de choix, reportez-vous à la section Créer une carte de champ.
Une base de données secondaire est toujours légèrement obsolète par rapport à la base de données primaire. Si votre importation nécessite des données totalement à jour, n’utilisez pas de stockage secondaire.