Deadlock sur les changements de valeur de la variable journalisation à l'aide d'une tâche SQL

Question

Matin

J'ai lu "SQL Server 2008 Integration Services Problème - Design - Solution". Il décrit une façon de consigner les modifications de variables que j'essaie de répliquer dans SQL 2005.

1. Créer des variables, par ex. PackageId, RecordsAffected. - Définissez Raise ChangeEvent sur true.
2. Créer une variable de chaîne g.g. strVariableValue. - Définissez Raise ChangeEvent sur false.
3. Dans le gestionnaire d'événements de package: OnVariableValueChanged, ajoutez une tâche de script "SCR Convert value to string".
4. Ajouter ReadOnlyVariables: System :: VariableValue
5. Ajouter ReadWriteVariables: User :: strVariableValue
6. Dans le script, définir une variable locale System :: VariableValue.value.tostring
7. Définissez la variable utilisateur :: strVariableValue à la variable locale
8. Ajoutez un composant "Exécuter une tâche SQL" "Valeur de variable de journal SQL modifiée" appelant un SP sans résultats.
9. Définissez le paramètre mappage utilisateur :: IDPack, System :: VariableName, utilisateur :: strVariableValue

Lorsque cela est exécuté, je reçois une impasse sur l'utilisateur :: PackageID

Erreur: 0xC001405B à SQL Log Variable Value Changed: Un blocage a été détecté lors de la tentative de verrouillage de la variable "User :: _ PackageID" pour un accès en lecture. Un verrou n'a pas pu être acquis après 16 tentatives et a expiré.

L'action de script réussit mais la tâche d'exécution SQL échoue. J'utilise Visual Studio 2005 version 8.0.50727.42, Microsoft SQL Server Integration Services Designer version 9.00.4035.00 et BIDSHelper version 1.4.3.0.

Des idées?

Answer 1

Eureka!

J'ai eu le même problème et conduit à quelques messages deadend, puis j'ai découvert la racine.

J'ai eu le cadre de travail très bien et je voulais forcer certaines informations à être enregistrées. J'ai donc changé la valeur de la variable d'infrastructure "strVariableValue" et cela a provoqué le blocage avec la tâche d'événement de changement. J'ai corrigé en créant ma propre variable "strLogMe" et en mettant tout ce que je voulais enregistrer.

moral: ne touchez pas les variables cadres

Answer 2

Avez-vous utilisé l'exemple de code du livre? Tous les fichiers sont disponibles sur le Wiley website for free. L'exemple de code inclut un package SSIS, des scripts SQL et un code VB pour le script. Si cela ne fonctionne pas pour vous, faites-le moi savoir car l'un des membres de mon équipe a trouvé un moyen de consigner les changements de variables qui étaient différents de cette méthodologie.

Answer 3

Je recevais cette erreur (« une impasse a été détectée », etc.), tout à coup, ce qui semblait coïncider avec i.t. avoir fait un correctif Microsoft Windows sur le serveur. Il y avait des paquets qui utilisaient des tâches de script, avec des variables en lecture seule et/ou en lecture-écriture dans l'interface utilisateur SSIS.Même si cela semblait avoir été un problème environnemental (parce que les paquets avaient fonctionné pendant des mois, puis soudainement cessé de fonctionner, même si je n'avais pas changé de code), je pensais bien (comme je l'avais vu de nombreux blogs depuis des années passé), il y avait des exemples de sociétés faisant des correctifs de serveur, puis ayant leurs paquets SSIS casser; et les blogs semblaient dire, changer la façon dont vous verrouillez les variables, ne les référencez pas dans l'interface utilisateur; à la place, verrouillez-les explicitement dans le code. J'ai donc essayé la même chose. Ça n'a pas arrangé ça.

Il s'est avéré que certains individus avaient supprimé les permissions de l'utilisateur sous l'identité duquel les paquets s'exécutaient, à partir du groupe AD; ces autorisations étaient nécessaires car il essayait de copier un fichier à partir d'un répertoire qui nécessitait des autorisations de lecture sur le répertoire. Ces packages sont généralement appelés par un travail d'agent SQL utilisant une identité de proxy. Lorsque le package a été exécuté manuellement à partir de SSMS, cela a fonctionné. Mais lorsqu'il a été exécuté en appelant le travail de l'agent SQL, il a échoué. En fin de compte, c'était juste une coïncidence que les paquets aient commencé à échouer au moment de la mise à jour de Windows. Mais l'autre point (principal) est, si votre paquet tente d'accéder à un fichier sur le réseau, et que l'identité (ou l'identité de proxy) sous laquelle ce paquet s'exécute n'a pas d'autorisations sur le répertoire source ou cible, alors votre paquet pourrait échouez et le problème pourrait se manifester de cette façon énigmatique, où il ressemble à un problème de blocage de variable, mais c'est en fait un problème d'autorisations de partage de fichiers. Je n'ai perdu qu'un jour là-dessus, mais ... peut-être que cela sera utile à quelqu'un dans le futur.