2010-12-09 31 views
4

Environnement: SQL Server 2008 R2 avec SSIS et SSAS.Composant de recherche SSIS - identifier les lignes ayant échoué/envoyer à la sortie de trace?

Courte question: Existe-t-il que SSIS envoie la ligne de données d'une recherche ayant échoué à un événement de trace?

Question longue: Je rassemble un certain nombre de packages SSIS qui effectuent un certain nombre de transformations sur des données à partir de tables contenant jusqu'à quelques millions de lignes. La destination finale est un cube SSAS. Toutes les recherches doivent réussir: l'échec indique qu'un problème de qualité des données s'est infiltré. L'échec de l'ensemble de l'ETL en cas de recherche échouée est donc correct.

Cependant, il ne semble pas y avoir de moyen facile de demander au composant SSIS Lookup de signaler quelle ligne a échoué lors de l'enregistrement dans le journal de suivi de la mention «Ligne écoulée sans correspondance pendant la recherche». Je cherche à voir s'il y a quelque chose que je peux faire pour attraper la ligne qui a échoué et obtenir les données de ligne enregistrées dans la trace en même temps.

Pour le moment, je dois utiliser des lignes non-assorties dans un fichier CSV pour l'analyse, mais cela signifie que le takeon continue le traitement, ce que je ne veux pas. En outre, accrocher un fichier sur chaque composant de recherche signifie gérer un grand nombre de fichiers supplémentaires (qui ont également besoin de la configuration des gestionnaires de connexions associés). Je pourrais, en théorie, gérer un seul fichier si j'alimentais toutes les sorties dans une transformation Union, mais quand je fais face à des paquets qui ont jusqu'à 10-15 transformations de recherche, cela devient désordonné très rapidement.

Je me demande s'il y a un moyen de me connecter à l'événement OnError pour obtenir ces données, mais si c'est le cas, ce n'est pas évident.

Toutes autres idées sont les bienvenues. Je ne peux pas croire que je sois le seul à me demander comment faire ça, mais mon stackoverflow-fu et google-fu m'ont abandonné et je ne peux (curieusement) rien y trouver ...

À votre santé!

+0

Voulez-vous dire une trace SQL ou le journal/table d'erreur DTS? – Sam

+0

Donc, vous voulez que votre 'takeon' arrête le traitement après la première recherche échouée? Ou voulez-vous qu'il affiche toutes les recherches échouées? Cela peut prendre beaucoup de temps si vous échouez sur la première erreur et que vous avez plusieurs problèmes de données dans le flux. – Sam

+0

@Sam - soit. En fin de compte, puis-je tracer la ligne problématique sans avoir à ajouter des éléments de flux de données supplémentaires à la config. Pour un fichier journal/table serait le mieux car alors il peut être consulté historiquement, mais dans profiler va bien aussi tbh. –

Répondre

0

Pourriez-vous rediriger ces lignes dans une table et y placer une colonne 'paquet source' pour les interroger ou rendre les rapports de correction plus simples?

Aussi, juste une idée, mais peut-être que vous pourriez rediriger toutes les sorties à la «sortie de la corbeille» sur ce page. Vous pouvez ensuite continuer à consigner les erreurs de recherche sans déplacer les données vers la table de destination.

+1

Le problème est que j'ai une demi-douzaine de transformations, la plus grande ayant environ 20 flux de données différents, la plus petite ayant deux flux de données, mais chaque flux de données peut avoir de deux à une douzaine de transformations de recherche. La redirection de lignes erronées vers une autre table va devenir assez désagréable assez rapidement, donc je préférerais juste avoir une sortie de débogage brute avec quelque chose qui me dit "Row n'a pas donné de résultat pendant la recherche de la valeur de {x}" ou l'envoi de la ligne Échec rapporté quelque part. En fin de compte, tout ce que je veux savoir, c'est * quelle est la valeur qui a échoué dans la recherche :-) –