Le package SSIS ne fait rien lorsqu'il est appelé par l'agent

Question

Le package SSIS fait une boucle dans les fichiers d'entrée. Flatfile parse ajoute des enregistrements à une table DB, puis le fichier est renommé/déplacé pour l'archivage. Après tous les fichiers, package appelle un sproc pour supprimer tous les enregistrements d'un an.

Le paquet fonctionne à partir de visual studio OK. Mettez dans le magasin de paquets SSIS, exécutez à partir de là, pas de problème.

Créez un travail d'agent SQL pour exécuter le package. Le travail fait quelque chose pendant environ cinq minutes, annonce qu'il était succès, mais pas de nouveaux enregistrements dans DB et pas de changement de nom des fichiers d'entrée. Le package utilise la connexion dédiée pour les privilèges SQL Server. Le travail est exécuté en tant que HOSTNAME-SVC qui dispose de droits en lecture/écriture sur le répertoire d'entrée et le répertoire d'archivage.

Answer 1

Avez-vous configuré la journalisation pour le package? Vous pouvez ajouter une tâche de script au conteneur de boucles For-Each qui exécute une commande Dts.Events.FireInformation lors de chaque boucle. Cela pourrait vous aider à suivre le nom de fichier qu'il trouve, le nombre de boucles qu'il fait, combien de temps chaque boucle prend, etc. Vous pouvez également ajouter une étape de journalisation à la fin pour que vous sachiez qu'il quitte au moins la boucle For-Each conteneur avec succès. Si vous constatez que le package fonctionne correctement mais ne parcourt aucun fichier, vous pouvez tester en utilisant un package plus simple qui lit un fichier uniquement et le charge dans une table de transfert. Si cela fonctionne, passez à l'étape suivante de boucler tous les fichiers dans le directeur et importer seulement le fichier encore et encore. Si cela fonctionne, passez à l'étape suivante de modification de la connexion de fichier pour faire correspondre le fichier qu'il trouve dans la tâche Enumérateur de fichier de conteneur de boucle For-Each.

Si le package ne parcourt aucun fichier et que vous ne parvenez même pas à voir le fichier que vous avez testé depuis le travail, essayez de créer un compte proxy avec vos informations d'identification et exécutez le travail comme proxy Compte. Si cela fonctionne, vous avez probablement un problème d'autorisations avec votre compte de service.

Si le package n'importait rien même avec le compte proxy, vous souhaiterez peut-être vous connecter au serveur en tant que compte de service et essayer d'exécuter le package SSIS dans BIDS. Si cela fonctionne, alors vous pouvez le déployer sur le serveur et exécuter le paquet à partir du serveur (qui utilisera vraiment votre machine, mais au moins il utilise la définition ssis du serveur). Si cela fonctionne, essayez d'exécuter le package à partir de l'agent.

Answer 2

Je ne suis pas sûr de bien comprendre. Le paquet a déjà été testé sous plusieurs comptes Windows, et il trouve tous les fichiers et renommer tous les fichiers.

Sous l'agent, il ne fait absolument rien de visible, mais prend cinq minutes pour le faire. PAS d'erreurs d'autorisations ou d'autres erreurs. Je n'ai pas mentionné qu'une tentative précédente a reçu des erreurs d'autorisations parce que nous n'avions pas donné l'accès au compte de service aux répertoires d'entrée et de sortie.

Je ne peux pas me connecter en tant que compte de service pour essayer cela car je n'ai pas de mot de passe pour cela. Mais son propriétaire d'emploi devrait être en mesure de passer au compte de service - et les erreurs d'accès que nous avons eues il y a dix jours montrent que c'est possible. Le paquet lui-même n'a pas changé au cours de ces dix jours. Nous venons de supprimer le travail afin de faire une «répétition générale» complète de la procédure de déploiement.

Donc, ce qui a changé, je présume, est un détail dans la procédure de déploiement, qui malheureusement n'était pas dans le contrôle de la source au moment où il a réussi.

Answer 3

Il semble que ce soit quelque chose de différent à propos des permissions. Nous avons fait disparaître le problème en autorisant "tout le monde" à lire le répertoire sur le serveur de production. Pour une raison inconnue, nous n'avions pas à le faire sur le serveur de test.

Lorsque le travail a tenté d'extraire la liste de fichiers, au lieu d'obtenir une erreur (qui serait enregistrée), il a obtenu une liste vide. Pourquoi boucler une liste vide a pris cinq minutes est toujours un mystère, tout comme le manque d'autorisations. Mais au moins ce qui s'est passé a été identifié.

Answer 4

J'ai eu un problème similaire. Était capable de comprendre ce qui se passait en définissant l'option de journalisation du travail de l'Agent SQL Server. Modifiez l'étape du travail qui exécute le package, accédez à l'onglet de journalisation et sélectionnez "Fournisseur de journal SSIS pour SQL Server" et, dans la chaîne de configuration, j'ai sélectionné (à l'aide de la liste déroulante) le connecteur OLEDB qui était dans le package, il arrive de se connecter à SQL Server en question.

J'ai ensuite pu voir plus de détails dans l'historique de ce travail, et j'ai confirmé qu'il ne trouvait pas de fichiers. En modifiant les autorisations sur le répertoire pour qu'il corresponde au compte de l'agent du serveur SQL, le package est finalement exécuté correctement.

Espérons que cela aide.

Vous souhaiterez peut-être désactiver la journalisation après avoir résolu votre problème, en fonction de la fréquence d'exécution de votre package et de la quantité d'informations fournies dans votre cas.

Cordialement, Bertin