Comment surmonter les mauvaises performances de débogage SSIS?

Question

J'utilise SSIS pour synchroniser les données entre deux bases de données. J’ai utilisé SSIS et DTS dans le passé, mais j’écris généralement une application pour des choses de cette nature (je suis un codeur et c’est plus facile pour moi).

Dans mon package, j'utilise une tâche SQL qui renvoie environ 15 000 lignes. Je l'ai reliée à un conteneur Foreach, et dans ce contexte, j'attribue les valeurs de colonne du jeu de résultats à des variables, puis je mappe ces variables à des paramètres alimentant une autre tâche SQL.

Le problème que je rencontre est lié au débogage, et pas seulement au débogage plus complexe, comme les points d'arrêt et l'évaluation des valeurs au moment de l'exécution. Je veux simplement dire que si je lance ceci avec le débogage plutôt que sans, cela prend des heures à compléter. J'ai fini par réécrire le processus dans Delphi, et voici ce que j'ai proposé:

Données complètes:
Cela extrait 15 000 lignes, met à jour une table de destination pour chaque ligne, puis 11 000 lignes et met à jour une table de destination pour chaque ligne.

Débogage:
App Delphi: 139s
SSIS: 4 heures, 46 minutes

Pas de débogage:
Application Delphi: 132s
SSIS: 384s

Mise à jour des données:
Cela extrait 3 000 lignes, mais aucune mise à jour n'est nécessaire ni apportée à la table de destination. Il extrait ensuite 11 000 lignes mais, là encore, aucune mise à jour n'est nécessaire ni apportée à la table de destination.

Débogage:
App Delphi: 42s
SSIS: 1 heure, 10 minutes

Pas de débogage:
App Delphi: 34s
SSIS: 205s

Ce qui est étrange, c’est que j’ai l’impression que la majeure partie de ce temps consacré au débogage consiste simplement à mettre à jour des éléments d’interface utilisateur dans Visual Studio. Si je regarde l'onglet de progression, un nœud est ajouté à une arborescence pour chaque itération (un total de milliers), et cela devient de plus en plus lent au fur et à mesure du déroulement du processus. Essayer d'arrêter le débogage ne fonctionne généralement pas, car Visual Studio semble pris dans une boucle mettant à jour l'interface utilisateur. Si je vérifie le profileur pour SQL Server, aucun travail réel n'est en cours. Je ne suis pas sûr que la machine compte, mais elle devrait être plus que pratique (quad core, 4 Go de RAM, carte vidéo de 512 Mo).

Ce genre de comportement est-il normal? Comme je l'ai déjà dit, je n'ai aucun problème à écrire une application pour ce genre de choses (en fait, il me faut beaucoup moins de temps pour coder une application que pour dessiner & # 8220; 8221; cela dans SSIS, mais je pense que cette marge diminuera avec davantage de travail dans SSIS), mais j’essaie de comprendre où quelque chose comme SSIS et DTS s’insérerait dans ma boîte à outils. Jusqu'à présent, rien de cela ne m'a vraiment impressionné. Peut-être que je abuse ou que je abuse de SSIS d'une manière ou d'une autre?

Toute aide serait grandement appréciée, merci d'avance!

Answer 1

Le flux de contrôle et les boucles SSIS ne sont pas très performants et ne sont pas conçus pour traiter ces quantités de données. En particulier pendant le débogage - avant et après chaque tâche, le débogueur envoie des notifications au processus du concepteur, qui met à jour les couleurs des formes, ce qui peut être lent.

Vous pouvez obtenir de bien meilleures performances en utilisant le flux de données. Le flux de données ne fonctionne pas avec des lignes simples, il fonctionne avec des tampons de lignes - beaucoup plus rapidement, et le débogueur est uniquement informé du début / de la fin des tampons - son impact est donc moins perceptible.

Answer 2

SSIS n’est pas conçu pour faire un foreach comme ça. Si vous faites quelque chose pour chaque ligne entrante, vous voudrez probablement les lire dans un flux de données, puis en utilisant une jointure de recherche ou de fusion, déterminez si vous souhaitez faire un INSERT (ceci se produit en bloc) ou un objet de commande de base de données pour plusieurs SQL UPDATE. commandes (une option plus performante consiste à les regrouper dans une table intermédiaire et à effectuer une seule mise à jour).

Dans une autre situation de synchronisation typique, vous lisez toutes les données dans une table intermédiaire et effectuez une MISE À JOUR SQL Server sur les lignes existantes (INNER JOIN) et sur INSERT sur les nouvelles lignes (LEFT JOIN, rhs IS NULL). Il est également possible d’utiliser des serveurs liés, mais les jointures peuvent être lentes car toutes les données (ou une grande partie de celles-ci) peuvent devoir passer par le réseau.

J'ai des packages SSIS qui importent régulièrement 24 millions de lignes, y compris la conversion et la conversion des données et les dimensions changeant lentement à l'aide du composant TableDifference. Il s'exécute relativement rapidement pour cette grande quantité de données par rapport à un programme client séparé.

Answer 3

J'ai remarqué que c'était le comportement. J'avais un paquet SSIS pour les déménagements. Il contenait environ 3 millions d'entrées. Il n'était pas possible de déboguer car il serait exécuté pendant environ 3-4 jours.

SSIS est toujours ce que j'ai fait, je ne fais tout simplement pas de "débogage". avec SSIS, je les exécute lorsque je travaille avec tous les jeux de données. Si je dois déboguer, j'utilise de très petits jeux de données.