Résoudre les problèmes de performances des ensembles de données à importer
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 de 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 à partir 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.
Ralentir les scripts de transformation
L’utilisation de plusieurs requêtes GlideRecord ou de boucles volumineuses 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 apparaître lorsque le script de transformation n’est pas efficace. Dans la plupart des cas, les objectifs de script peuvent être atteints à l’aide des fonctionnalités intégrées à l’application Import Set. Par exemple, vous pouvez créer un script de 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 la fonctionnalité 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 : L’ensemble de données à importer prend plus de temps que prévu. Sous , attendez-vous à voir une importation avec un nombre total très élevé avec un nombre ignoré également très élevé - ce nombre se trouve sous la colonne Message . Indiquant que la plupart des documents importés n’avaient pas réellement changé. Ces enregistrements n’ont pas eu 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 la source de données de votre 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.
Fusion sur les champs non indexés
La fusion sur des champs non indexés avec une grande quantité de données peut ralentir les transformations.
Devient un problème : lors de la mise en correspondance de champs qui ne sont pas indexés, cela ralentit l’exécution de l’étape de transformation d’une importation. 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 avec la base de données en raison de la 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 à voir des temps de transformation élevés.
Comment éviter cela : Si possible, vous devez fusionner sur 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 a une icône bleue avec un i en regard si elle est indexée. Pour obtenir de l’aide sur l’indexation d’un champ, contactez ServiceNow l’assistance technique.
Exécution simultanée d’importations
L’exécution simultanée d’importations peut entraîner une charge excessive sur la base de données.
Devient un problème : l’importation de grandes quantités de données impose une charge supplémentaire à 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 du système en raison de la charge accrue 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. En outre, 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 s’exécutant lentement combinées à une 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 pour qu’elles ne se chevauchent pas.
Tables de jeux d’importation volumineuses
Si les tables des ensembles de données à importer ne sont pas nettoyées, ces tables peuvent devenir encombrées et lentes.
Devient un problème : lorsque la tâche Import Set Deleter n’est pas en cours d’exécution.
Symptômes : Il s’agit d’un problème de taille. Si les ensembles de données à importer ne sont pas nettoyés régulièrement (un nettoyage est recommandé après sept jours de données), la table se remplit, ce qui entraîne l’arrêt des importations.
Comment éviter cela : Vérifiez que la tâche Import Set Deleter 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 en important une nouvelle colonne, verrouille la table de jeux d’importation.
Devient un problème : chaque fois qu’une nouvelle colonne est importée, l’ensemble de la table d’ensembles de données à importer est verrouillé pendant ce changement de schéma et, selon 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 jeu de données très volumineux 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 très grand ensemble de données en plusieurs tâches plus petites pour des résultats plus rapides. À titre indicatif, prenez en compte les ensembles d’importation de moins de 100 000 enregistrements. Par exemple, l’importation de 10 ensembles de 100 000 enregistrements s’effectue plus rapidement qu’une importation de 1 million d’enregistrements, même si le nombre total de 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 avec de nombreuses références à résoudre peut prendre plus de temps que prévu ou entraîner un ralentissement de la base de données.
Devient un problème : lors de l’utilisation d’une carte de transformation pour des importations de données volumineuses 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, réduisant ainsi la charge sur la base de données principale.
- Activez le module d’extension Pools de bases de données secondaires [com.glide.secondary_db_pools]. Pour plus d'informations, consultez Request a plugin.
- Confirmez que la catégorie de 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 .Créer une carte de transformation Utilisez cette case à cocher pour activer ou désactiver le stockage secondaire.
Lorsque vous utilisez un stockage secondaire, définissez le champ d’action Choix dans la carte de champs sur ignorer ou rejeter. Définir l’action Choix sur créer peut entraîner la création de plusieurs copies d’un enregistrement, 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 champs.
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 complètement à jour, n’utilisez pas de stockage secondaire.