SSIS Erreur de variable intermittente: le système ne trouve pas le fichier spécifié

Question

Notre SSIS regroupe un package de contrôle structuré en un seul et de nombreux packages enfants (environ 30) qui sont appelés à partir du package de contrôle. Les packages enfants sont appelés avec la tâche d'exécution de package. Il existe une tâche d'exécution de paquet par paquet enfant. Chaque tâche d'exécution de package utilise Gestionnaire de connexions de fichiers pour spécifier le chemin d'accès au fichier dtsx du package enfant. Il y a un Gestionnaire de connexion de fichiers par paquet enfant. Chaque gestionnaire de connexion de fichiers a une expression définie pour la propriété ConnectionString. Cette expression ressemble à ceci:

@[Template::FolderPackages]+"MyPackage.dtsx" 

Le nom de fichier est différent pour chaque paquet. La variable (FolderPackages) est spécifiée dans le fichier de configuration du package SSIS.

L'erreur qui est générée lors de l'exécution est

Error 0x80070002 while loading package file "MyPackage.dtsx"

Le système ne peut pas trouver le fichier spécifié. » Le package qui ne diffère de la course à courir et parfois aucun paquet échouent tout. C'est quand J'ai exécuté FileMon pendant cette erreur et j'ai découvert que lorsque l'erreur se produit, SSIS essaie de lire le fichier dtsx à partir d'un mauvais emplacement, à savoir de system32. à ce qui se passerait si la variable @ [Template :: FolderPackages] était vide, mais parce que la même variable est utilisée pour chaque paquet d'enfant et travaille pour certains mais ne fonctionne pas parfois pour d'autres, je n'ai aucune expalnation à ce fait.

Quelque chose d'évident, ou le temps d'élever un appel de support avec Microsoft?

Answer 1

La réponse officielle à ce problème est qu'il s'agit d'un bogue dans SQL 2005 et 2008. Plusieurs tâches accédant à la même variable provoquent une condition de concurrence et certaines tâches obtiennent la valeur par défaut de l'expression au lieu de la valeur évaluée. La solution de contournement consiste à s'assurer que la valeur par défaut (la valeur définie dans la feuille de propriétés pour toute propriété avec laquelle vous rencontrez des problèmes) doit être la valeur qui fonctionnera dans votre environnement de production. De cette façon, lorsque la condition de concurrence se produit dans prod, SSIS reviendra à la valeur du package, qui fonctionnera toujours.

En cours? Eh bien, vous allez devoir faire face manuellement jusqu'à ce que nous obtenions un correctif de Microsoft.

Answer 2

Un peu d'un coup de poignard dans le noir, mais ...

J'ai eu un problème similaire avec des variables où = readonly composants faux et multiples ont été lecture de la variable en même temps et causer des problèmes de verrouillage.

J'ai régulièrement recréé le problème en exécutant une paire de flux de données qui ne faisait que référencer la variable dans un conteneur de boucle for et qui modifiait la variable en lecture seule, ce qui résolvait le problème.

Si vous codez temporairement le nom du package, cela résout-il le problème?

Answer 3

Il s'avère après avoir envoyé des informations de suivi à Microsoft que nous rencontrons une corruption de tas. Je vais mettre à jour cette question si nous arrivons au fond de celui-ci. La suggestion actuelle est de désactiver le lookasside tas pour dtexec.exe.

Answer 4

Utilisez-vous directement des expressions sur les variables SSIS?Les variables avec des expressions sont calculées chaque fois que la variable est référencée par l'objet consommateur qui doit l'utiliser. C'est là que le problème de condition de concurrence existe, car parfois l'expression n'est pas évaluée si un autre thread évalue déjà une variable différente, et la valeur par défaut de la variable est fournie à l'objet consommateur.

Si qui correspond à votre conception, ces deux bugs sur le site de connexion discutent du problème et les solutions de contournement:

https://connect.microsoft.com/SQLServer/feedback/details/332372/ssis-variable-expressions-dont-always-evaluate

une seconde à connect.microsoft.com/SQLServer/feedback/details/406534/SSIS-2008-variable-expressions-dont-toujours-évaluer

Un résumé des solutions de contournement est { - Notez les tâches parallèles qui pourraient fonctionner en vous flux de contrôle SSIS et utiliser ces variables d'expression. Si vous avez deux tâches côte à côte si chacune dépend de la même variable, et que cette variable a une expression pour définir sa valeur, alors vous pouvez frapper ceci. Effectuez une séquençage manuel de ces tâches afin qu'elles ne s'exécutent pas en parallèle. C'est à dire. Ajouter une flèche verte sur le flux de contrôle, de sorte que les tâches se produisent dans l'ordre Task1, Task2, Task3, plutôt que côte à côte sur les chemins parallèles et plutôt que dans le même conteneur sans chemins.

• Vous pouvez éviter des expressions variables: Attribution des variables locales dans l'ordre requis à l'aide d'une tâche de script fait maison qui fait le même genre de travail, de sorte que les variables ne sont pas évaluées en utilisant des expressions (la chose qui peut. frapper cette condition de course). En d'autres termes, attribuez manuellement les valeurs des variables à un moment donné dans votre flux de contrôle juste avant qu'elles ne soient utilisées. Le point d'utilisation des expressions sur les variables est de définir dynamiquement une valeur basée sur une autre valeur à chaque fois qu'elle est utilisée, ce qui permet d'atteindre un objectif de conception similaire, mais de manière manuelle. Réduire les threads pour minimiser le potentiel: Définir la tâche Dataflow EngineThreads sur 1 et MaxConcurrentExecutables sur 1. Cela permettra de séquencer l'exécution de votre package à une tâche à la fois, mais cela a l'effet secondaire qui peut ralentir les performances.

• Créer et définir des valeurs sur des copies distinctes de variables à différents niveaux de portée dans la conception, afin qu'elles évaluent dans différentes étendues d'exécution parallèles et évitent l'évaluation d'expression sur les threads parallèles. Maître :: Var1, Enfant1 :: Var1, Enfant2 :: Var1

}

Answer 5

Il y a un article KB relatif à cette question: http://support.microsoft.com/kb/2448991 qui indique quand et où cela a été fixé.