Dépannage de l'exécution des packages

Article
12/15/2008

Mis à jour : 12 décembre 2006

Integration Services intègre des fonctionnalités et des outils que vous pouvez utiliser pour résoudre des problèmes liés aux packages que vous exécutez après les avoir menés à terme et les avoir déployés.

Au moment de la conception, Business Intelligence Development Studio fournit des points d'arrêt permettant d'arrêter l'exécution des packages, une fenêtre Progression et des visionneuses de données à l'aide desquelles vous pouvez observer les données qui traversent le flux de données. Néanmoins, ces fonctionnalités ne sont pas disponibles lorsque vous exécutez des packages que vous avez déployés. Les principales techniques de dépannage des packages déployés sont les suivantes :

Détection et traitement des erreurs liées aux packages par le biais de gestionnaires d'événements.
Capture de données incorrectes à l'aide de sorties d'erreur.
Suivi des étapes d'exécution des packages à l'aide de la fonction de journalisation.

Vous pouvez également suivre les conseils et les techniques suivantes pour éviter tout problème lors de l'exécution des packages :

Renforcez l'intégrité des données à l'aide de transactions. Pour plus d'informations, consultez Incorporation des transactions dans les packages.
Utilisez des points de contrôle pour redémarrer les packages à compter du point de défaillance. Pour plus d'informations, consultez Utilisation des points d'arrêt dans les packages.

Détection et traitement des erreurs liées aux packages à l'aide de gestionnaires d'événements

Vous pouvez répondre aux nombreux événements engagés par le package et les objets de ce dernier par le biais de gestionnaires d'événements.

Créez un gestionnaire d'événements pour l'événement OnError. Dans le gestionnaire d'événements, vous pouvez recourir à une tâche Envoyer un message pour signaler l'échec à un administrateur, utiliser une tâche de script et une logique personnalisée pour recueillir des informations système à des fins de dépannage ou bien nettoyer les ressources temporaires ou une sortie incomplète. Pour plus d'informations, consultez Gestionnaires d'événements d'Integration Services et Création de gestionnaires d'événements pour un package.

Résolution des problèmes liés aux fournisseurs de données externes

Beaucoup de packages échouent lorsqu'ils communiquent avec des fournisseurs de données externes. Néanmoins, les messages que retournent ces fournisseurs à Integration Services apportent souvent des informations insuffisantes pour commencer à résoudre cet échec de communication. Pour traiter ce problème, Microsoft SQL Server 2005 Service Pack 2 (SP2) inclut de nouveaux messages de journalisation qui vous permettent de résoudre les problèmes d'interaction d'un package avec des sources de données externes.

Activez la journalisation et sélectionnez l'événement Diagnostic du package pour afficher les nouveaux messages de journalisation. À partir de SP2, les composants Integration Services suivants vous permettent d'écrire un message dans le journal avant et après chaque appel à un fournisseur de données externes :

Gestionnaire de connexions OLE DB, source OLE DB et destination OLE DB
Gestionnaire de connexions ADO.NET et source DataReader
Tâche d'exécution de requêtes SQL
Transformation de recherche, transformation de commande OLE DB et transformation de dimension à variation lente

Les nouveaux messages de journalisation comprennent le nom de la méthode appelée. Par exemple, ils peuvent inclure la méthode Open d'un objet OLE DB Connection ou la méthode ExecuteNonQuery d'un objet Command. Les messages adoptent le format suivant où '%1!s!' désigne un espace réservé aux informations de la méthode :

ExternalRequest_pre: The object is ready to make the following external request: '%1!s!'.
ExternalRequest_post: '%1!s!'. The external request has completed.

Pour résoudre les problèmes d'interaction avec le fournisseur de données externes, passez en revue le journal pour savoir si chaque message transmis « avant » (ExternalRequest_pre) dispose d'un message transmis « après » (ExternalRequest_post) correspondant. Si aucun message postérieur correspondant n'existe, vous savez alors que le fournisseur de données externes n'a pas répondu comme prévu.
L'exemple suivant dévoile quelques exemples de lignes d'un journal contenant les nouveaux messages de journalisation :

ExternalRequest_pre: The object is ready to make the following external request: 'ITransactionJoin::JoinTransaction'.
ExternalRequest_post: 'ITransactionJoin::JoinTransaction succeeded'. The external request has completed.
ExternalRequest_pre: The object is ready to make the following external request: 'IDbConnection.Open'.
ExternalRequest_post: 'IDbConnection.Open succeeded'. The external request has completed.
ExternalRequest_pre: The object is ready to make the following external request: 'IDbConnection.CreateCommand'.
ExternalRequest_post: 'IDbConnection.CreateCommand finished'. The external request has completed."
ExternalRequest_pre: The object is ready to make the following external request: 'IDbCommand.ExecuteReader'.
ExternalRequest_post: 'IDbCommand.ExecuteReader finished'. The external request has completed."
ExternalRequest_pre: The object is ready to make the following external request: 'IDataReader.GetSchemaTable'.
ExternalRequest_post: 'IDataReader.GetSchemaTable finished'. The external request has completed."
ExternalRequest_pre: The object is ready to make the following external request: 'IDataReader.Close'.
ExternalRequest_post: 'IDataReader.Close finished'. The external request has completed."
ExternalRequest_pre: The object is ready to make the following external request: 'IDbConnection.Close'.
ExternalRequest_post: 'IDbConnection.Close finished'. The external request has completed."

Dépannage de données incorrectes à l'aide de sorties d'erreur

Vous pouvez exploiter la sortie d'erreur disponible dans nombre de composants de flux de données pour orienter les lignes contenant des erreurs vers une destination distincte en vue d'une analyse ultérieure.

Capturez les données incorrectes à l'aide de sorties d'erreur. Transmettez les lignes qui contiennent des erreurs à une destination distincte, telle qu'une table d'erreurs ou un fichier texte. La sortie d'erreur ajoute automatiquement deux colonnes numériques renfermant le numéro de l'erreur responsable du rejet de la ligne, ainsi que l'ID de la colonne dans laquelle l'erreur est survenue. Pour plus d'informations, consultez Gestion des erreurs dans les données et Procédure : configurer une sortie d'erreur dans un composant de flux de données.
Dotez les sorties d'erreur d'informations conviviales. Vous pouvez faciliter le travail d'analyse de la sortie d'erreur en ajoutant des informations descriptives, en plus des deux identificateurs numériques fournis par la sortie d'erreur.
Affichez la description de l'erreur. Vous pouvez aisément rechercher une description de l'erreur à l'aide d'un composant Script. Pour plus d'informations, consultez Enhancing an Error Output with the Script Component.
Ajoutez le nom de la colonne d'erreur. La recherche du nom de colonne correspondant à l'ID de colonne enregistré dans la sortie d'erreur n'est pas facile dans le composant Script et exige d'autres étapes. Chaque ID de colonne au sein d'un flux de données est unique dans la tâche de flux de données concernée et demeure dans le package au moment de la conception. L'approche suivante est une solution qui suggère l'ajout du nom de la colonne à la sortie d'erreur :
1. Créez une table de recherche des noms de colonnes. Créez une application qui utilise l'API Integration Services pour intervenir de manière itérative dans chaque package enregistré, chaque flux de données au sein du package, chaque objet au sein du flux de données, puis chaque entrée ou sortie dans l'objet du flux de données. L'application doit conserver l'ID de colonne et le nom de chaque colonne dans une table de recherche, ainsi que l'ID de la tâche de flux de données parent et celui du package.
2. Ajoutez le nom de la colonne à la sortie. Ajoutez une transformation de recherche à la sortie d'erreur chargée de rechercher le nom de colonne dans la table de recherche créée à l'étape précédente. La recherche peut se servir de l'ID de colonne dans la sortie d'erreur, de l'ID du package (disponible dans la variable système System::PackageID) et de l'ID de la tâche de flux de données (disponible dans la variable système System::TaskID).

Dépannage de l'exécution des packages à l'aide de la journalisation

Vous pouvez contrôler la plupart des opérations réalisées dans vos packages en cours d'exécution en activant la fonction de journalisation. Les modules fournisseur d'informations permettent de capturer des informations sur des événements spécifiques à des fins d'analyse ultérieure, puis d'enregistrer ces informations dans une table de base de données, un fichier plat, un fichier XML ou un autre format de sortie pris en charge.

Activez la journalisation. Vous pouvez affiner la sortie de journalisation en choisissant uniquement les événements et les éléments d'information que vous souhaitez capturer. Pour plus d'informations, consultez Modules fournisseurs d'informations d'Integration Services et Implémentation de la journalisation dans les packages.
Sélectionnez l'événement Diagnostic du package pour résoudre les problèmes inhérents au fournisseur. SP2 propose de nouveaux messages de journalisation qui vous permettent de résoudre les problèmes d'interaction d'un package avec des sources de données externes. Pour plus d'informations, consultez la section Résolution des problèmes liés aux fournisseurs de données externes de cette rubrique.
Améliorez la sortie de journalisation par défaut. La journalisation ajoute généralement des lignes à la destination de journalisation à chaque exécution d'un package. Bien que chaque ligne de la sortie de journalisation identifie le package par son nom et son identificateur unique, ainsi que l'exécution du package par un ExecutionID unique, une grande partie de la sortie de journalisation au sein d'une seule liste peut s'avérer difficile à analyser. L'approche suivante est une suggestion possible pour améliorer la sortie de journalisation par défaut et la rendre plus facile pour la génération de rapports :
1. Créez une table parent chargée de consigner chaque exécution d'un package. Cette table parent dispose d'une seule ligne pour chaque exécution d'un package et utilise l'ExecutionID pour établir un lien avec les enregistrements enfants de la table de journalisation Integration Services. Vous pouvez exécuter une tâche d'exécution SQL au début de chaque package pour créer cette nouvelle ligne et enregistrer l'heure de début. Vous pouvez ensuite utiliser une autre tâche d'exécution SQL à la fin du package pour mettre à jour la ligne avec l'heure de fin, la durée et l'état.
2. Ajoutez des informations d'audit au flux de données. Vous pouvez utiliser la transformation d'audit pour ajouter aux lignes du flux de données des informations sur l'exécution de package ayant entraîné la création ou la modification de chaque ligne. La transformation d'audit met neuf éléments d'information à disposition, notamment les variables PackageName et ExecutionInstanceGUID. Pour plus d'informations, consultez Transformation d'audit. Si vous disposez d'informations personnalisées que vous aimeriez inclure dans chaque ligne à des fins d'audit, vous pouvez les ajouter aux lignes dans le flux de données à l'aide d'une transformation de colonne dérivée. Pour plus d'informations, consultez Transformation de colonne dérivée.
3. Si possible, capturez les données sur le nombre de lignes. Si possible, créez une table séparée pour les informations concernant le nombre de lignes dans laquelle chaque instance d'exécution de package est identifiée par son ExecutionID. Utilisez la transformation de calcul du nombre de lignes pour enregistrer le nombre de lignes dans une série de variables à des étapes critiques du flux de données. À la fin du flux de données, utilisez une tâche d'exécution SQL pour insérer la série de valeurs dans une ligne de la table en vue d'une analyse et d'un rapport ultérieurs.

Dépannage des problèmes de validation au moment de l'exécution

Il est possible parfois que vous ne parveniez pas à vous connecter à vos sources de données ou que des parties de votre package ne puissent pas être validées jusqu'à ce que les précédentes tâches du package aient été exécutées. Grâce aux fonctionnalités suivantes de Integration Services, vous évitez toute erreur de validation susceptible de survenir dans ces conditions :

Configurez la propriété DelayValidation dans les éléments de package non valides lors du chargement du package. Pour éviter des erreurs de validation lors du chargement du package, vous pouvez définir la propriété DelayValidation à True dans des éléments de package dont la configuration n'est pas valide. Par exemple, vous pouvez disposer d'une tâche Flux de données qui utilise une table de destination qui n'existe pas jusqu'à ce qu'une tâche d'exécution SQL crée la table au moment de l'exécution. La propriété DelayValidation peut être activée au niveau du package ou au niveau des tâches individuelles et des conteneurs inclus dans le package.
La propriété DelayValidation peut être définie sur une tâche Flux de données mais pas sur des composants de flux de données individuels. Vous pouvez obtenir un résultat similaire en définissant la propriété ValidateExternalMetadata des composants de flux de données individuels à false. Néanmoins, si cette propriété affiche la valeur false, le composant n'a pas connaissance des modifications apportées aux métadonnées des sources de données externes. Lorsqu'elle est définie à true, la propriété ValidateExternalMetadata peut permettre d'éviter des problèmes de blocage provoqués par un verrouillage dans la base de données, surtout lorsque le package utilise des transactions.

Dépannage des problèmes d'autorisations au moment de l'exécution

Si vous rencontrez des erreurs lorsque vous tentez d'exécuter des packages déployés à l'aide de l'Agent SQL Server, il est possible que les comptes employés par ce dernier ne disposent pas des autorisations nécessaires. Pour plus d'informations sur le dépannage des packages exécutés à partir de travaux de l'Agent SQL Server, consultez l'article Un package SSIS ne s'exécute pas lorsque vous l'appelez à partir d'une étape du travail de l'Agent SQL Server dans la Base de connaissances Microsoft. Pour plus d'informations sur l'exécution de packages à partir de travaux de l'Agent SQL Server, consultez Planification de l'exécution d'un package dans l'Agent SQL Server et Procédure : exécuter un package à l'aide du travail de l'Agent SQL Server.

Dépannage des problèmes 64 bits

Si vous rencontrez des erreurs sur un serveur 64 bits dotés de packages exécutés avec succès en mode 32 bits ou sur des serveurs 32 bits, tenez compte des problèmes courants suivants. Pour plus d'informations, consultez Observations relatives à Integration Services sur des ordinateurs 64 bits.

Certains fournisseurs de données ne sont pas disponibles sur la plateforme 64 bits. C'est notamment le cas du fournisseur Microsoft OLE DB pour Jet nécessaire pour la connexion à des sources de données Excel ou Access : il n'est pas disponible dans une version 64 bits.
Pour être utilisés sur un ordinateur 64 bits, les scripts doivent être précompilés sur un ordinateur 32 bits. Dans les packages qui utilisent des tâches de script ou des composants Script, la propriété PreCompile doit être définie à True.
Les packages DTS ne peuvent pas être exécutés en mode 64 bits. Si votre package exécute des packages DTS (Data Transformation Services) SQL Server 2000 à l'aide de la tâche d'exécution de package DTS 2000, vous devez exécuter le package en mode 32 bits. Aucune prise en charge de l'exécution des packages DTS n'est proposée en mode 64 bits.

Dépannage des erreurs sans description

Si vous rencontrez une erreur Integration Services sans description qui l'accompagne, vous pouvez localiser cette dernière dans Integration Services Error and Message Reference en recherchant l'erreur d'après son numéro. La liste ne comporte aucune information de dépannage à cette étape.

Voir aussi

Historique des modifications

Version	Historique
12 décembre 2006	Nouveau contenu Ajout d'informations sur la manière dont SQL Server 2005 SP2 inclut de nouveaux messages de journalisation avec lesquels les utilisateurs peuvent résoudre des problèmes liés aux fournisseurs externes.