Garder les DTS Package Logs sur les rails

Pour valider la journalisation de packages basée sur un fichier texte, il faut fournir
un nom de fichier Error file sur l’onglet Logging dans la boîte de dialogue
DTS Package Properties, illustrée figure 1. Le nom Error file est trompeur
parce que la journalisation basée sur un fichier de texte capture l’information
de journalisation de package même en l’absence de toute erreur.
Le DTS package log fournit une information résumée sur l’exécution
du package ainsi que sur chaque étape qui le constitue. La figure 2 montre
un exemple de DTS package log. La première section du journal donne
une information d’exécution résumée sur tout le package. Parmi les mesures
que le journal capture, celles que vous consulterez le plus fréquemment
sont Executed On, Executed By, et quelques autres concernant le
temps d’exécution. L’entrée Executed On indique la machine physique
sur laquelle le package s’est exécuté. Cette information est très importante
quand on essaie de détecter et de dépanner des erreurs d’exécution
liées à  la portabilité, particulièrement quand on déplace un package d’un
serveur sur un autre. (Pour en savoir plus sur la portabilité du package
DTS, voir « DTS itinérant », SQL Server Magazine octobre 2003.) L’entrée
suivante, Executed By, indique l’utilisateur ou le processus à  l’origine du
package. Cette information est importante pour diagnostiquer des défaillances
liées à  la sécurité parce que, comme l’explique l’article « DTS itinérant »,
les packages DTS assument le contexte de sécurité de l’utilisateur à  l’origine du
package.
Les quelques entrées suivantes donnent des mesures de temps sur le package :
heure de début, heure de fin et temps d’exécution total. Ces mesures permettent de recueillir les informations de performances sur le package.
Au fil du temps, on pourra utiliser ces mesures de performances
pour créer une ligne de base servant à  mesurer
les effets des changements apportés aux volumes de données
ou aux règles de traitement.
Le reste du journal contient des informations d’exécution
à  propos de chacune des étapes du package : état
d’avancement, heure de début, de fin et temps d’exécution
en secondes pour chaque étape, et le comptage d’avancement.
De tous, l’état d’avancement et les temps d’exécution
sont généralement les mesures les plus intéressantes pour
isoler des problèmes d’exécution du package. L’état d’avancement
permet de savoir rapidement quelles étapes ont
réussi, échoué, ou n’ont même pas été exécutées. Les temps
d’exécution permettent de détecter des goulets d’étranglement
de performances. Le comptage d’avancement suit le
nombre d’enregistrements importés pour les tâches qui traitent
des données (la Transform Data Task, par exemple).