par Shane Dovers - Mis en ligne le 9/12/2004 - Publié en Février 2004
Un log bien bichonné donne de précieuses informations pour le dépannage
Il est parfois difficile d'isoler des problèmes DTS (Data Transformation
Services) quand on ne sait pas ce qui s'est produit pendant l'exécution d'un package
DTS. Heureusement DTS possède des fonctions de jiurnalisation de package
intégrées qui fournissent une précieuse source d'informations pour dépanner et
superviser l'exécution d'un package ...Avec SQL Server 2000, DTS offre deux méthodes
pour capturer l'information du journal. La première méthode - et la seule
acceptée par SQL Server 7.0 - journalise les erreurs et l'information d'exécution
dans un fichier texte. La seconde méthode, introduite dans SQL Server 2000, journalise
les erreurs dans une base de données. Les deux méthodes fournissent essentiellement
la même information d'exécution. Toutefois, comme leurs descriptions
l'indiquent, leur format de sortie est différent et, par conséquent, leur mode
de gestion aussi. Dans cet article, j'examine la méthode basée sur un fichier texte
pour capturer l'information d'un DTS Package Log, qui s'applique à la fois à SQL
Server 2000 et 7.0. Voyons l'information que contient le DTS Package Log, examinons
les caractéristiques de journalisation, puis appliquons une méthode pour gérer
les logs DTS basés sur un fichier texte qui utilise le code VBScript avec un job
SQL Server Agent planifié.
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).
Téléchargez cette ressource
![Comment lutter contre le Phishing ?](https://www.itpro.fr/wp-content/uploads/2024/07/Special-Report-Eviden-Securite-Phishing-Juillet-2024.png)
Comment lutter contre le Phishing ?
Dans un environnement cyber en constante mutation, le phishing évolue vers des attaques toujours plus sophistiquées combinant IA, automatisation et industrialisation. Une réalité complexe qui exige des mesures de sécurité avancées et repensées au-delà de l’authentification multifacteur. Découvrez les réponses technologiques préconisées par les experts Eviden et les perspectives associées à leur mise en œuvre.
Les articles les plus consultés
- Intelligence Artificielle : DeepKube sécurise en profondeur les données des entreprises
- 9 défis de transformation digitale !
- La blockchain en pratique
- Stockage autonome, Evolutivité & Gestion intelligente, Pure Storage offre de nouvelles perspectives aux entreprises
- 10 grandes tendances Business Intelligence
Les plus consultés sur iTPro.fr
- Impact de l’IA générative sur le lieu de travail
- Red Sift : une proposition clé pour sécuriser le patrimoine numérique
- Cloud Temple : le cloud de confiance de référence du marché français et européen
- Fusion d’identités avec Binary Tree Directory Sync Pro
- Contrôler et optimiser les dépenses informatiques dans le contexte macroéconomique actuel
![Revue Smart DSI](https://www.itpro.fr/wp-content/uploads/2024/07/SMART-DSI-Numero-34-Juin-2024.jpg)