Discussion :

[bridaine]

Bonjour,

J'ai terminé ma phase de développement sur SSIS 2 k5.

Après avoir par tous les moyens essayé vainement de faire tourner l'Agent SQL Server celui-ci fonctionne mais sans rien faire.
Pourtant nous avons suivi à la lettre les instructions du tutoriel de Fleur-Anne Blain qui semble très complet sur le sujet.

Il semblerait que ce soit un problème de droit que personne ne sait résoudre.

Je suis donc condamné à utiliser des packages DTSRUN pour automatiser.

Evidemment, je ne sais pas comment ça marche, la syntaxe n'est pas des plus simples.

J'ai besoin de programmer une heure de lancement, une période(jour) pour lancer mes packages dans l'ordre (qui devrait être le même que celui des steps de l'Agent Sql Server).

Y-a-t-il un tutoriel ou un des exemples simples sur l'automatisation avec DTSRUN ?

Merci d'avance et super aprés-midi

[Ptit_Dje]

Bonjour,

Qu'avez vous comme erreur ?
Quel est la valeur définie au niveau du parametre protectionlevel de vos packages ?
Pourquoi utiliser dtsrun et pas dtexec ?
Vos packages sont ils dépendants les uns des autres ? Si vous souhaitez tout scheduler dans différents steps d'un job, pourquoi ne pas créer un package pilote déclanchant un à un les packages et scheduler uniquement celui-ci?

Bonne journée

[bridaine]

Bonjour Ptit_Dje

C'est gentil de venir à mon secours, je viens de transmettre les suggestions au responsable technique pour éclaircir la situation qui n'est pas brillante pour le moment car l'Agent SQL Server a disparu avec le changement de serveur.

Prenons les questions dans l'ordre :
1_ Il n'y a aucun messages d'erreur avec l'Agent qui jusque là exécutait job et step (il n'y en avait qu'un au départ pour tester) : "success" et voyants au vert mais le chargement de données dans la table n'avait pas été fait (donc le package SSIS n'avait pas été exécuté)

2_ Je ne sais pas où se trouve le paramètre protectionlevel dans les packages (à moins que ce soit au niveau de l'Agent, mais où ?)

3_ Mon responsable technique au niveau client m'a dit que jusqu'à présent personne dans le service n'avait utilisé l'Agent mais DTSRun (c'est tout ce que je sais pour le moment)

4 _ Les packages obéissent à une suite logique :
a_ Traitement en cascade des logs applicatifs (fichiers plats traités et archivés) pour un découpage grossier en table de chargement (avec récupération du nom de fichier en première colonne)
b_ Alimentation de la table des Sessions (extrait de fichiers plats traités et archivés) qui est à part
c_ Alimentation de la table des Faits à partir de la table de chargement
d_ Alimentation de la table des Faits complétée par les enregistrements du broker (extrait d'un fichier plat à alimentation continue)
e_ Alimentation de la table des Références à partir des Faits (procédure de moindre importance)

Il y a possibilité par requêtes de regrouper des informations de mêmes serveurs et datasources pour effectuer des parallèles entre table des Faits et table des Sessions.

5_ pour ce qui est du package pilote, j'avoue qu'on n'en est pas encore là vu qu'au niveau de l'Agent SQL Server c'est la théorie et la pratique selon Einstein : "Ici nous avons réuni la théorie et la pratique, rien ne fonctionne et personne ne sait pourquoi !"

J'espère que l'Agent SQL Server sera de nouveau opérationnel ou que j'en saurai plus d'ici ce soir.

Merci encore et bonne journée

[Ptit_Dje]

Bonjour,

1-Concernant l'agent, regardez au niveau de l'output du step.
Je me suis rendu compte que même si un job était "correctement exécuté", une erreur peut être remontée dans les détails du step, cependant laissant celui-ci à un status de succès.

2-Le paramètre protection level se trouve dans les propriétés d'un package. Pour obtenir l'information, ouvrez le package avec BIDS (business intelligence development Studio), placez vous au niveau de l'onglet du control flow, cliquez sur l'espace de travail "package" (hors de toute tache ou container), ensuite dans la fenètre de propriété (accessible grace à la touche f4 si jamais), vous devriez pouvoir trouver cette propriété. Elle défini la sécurité de votre package. Il y a différents niveau de sécurité, l'encryption définie sur le user key, crée une clef basée sur le compte utilisateur et la machine, ce qui peut poser un problème pour la lecture du package par l'agent qui pourrait tourner sous un autre compte et sur une autre machine. Vous pouvez y préférer une encryption par mot de passe, parfois un peu ennuyante mais qui pose moins de soucis. Attention de ne pas perdre celui-ci

3-A priori, rien n'empèche d'utiliser l'agent.
Petite remarque supplémentaire, DTSRUN a été remplacé par DTEXEC depuis 2005, je vous recommande d'utiliser cet exécutable plutot.

4-Je vous recommanderai de créer un package "pilote", celui ci exécutant vos différents packages dans l'ordre. Il existe une tache au niveau des controls flow permettant l'exécution des packages. Cela vous permet en cas d'echec de l'un ou l'autre de pouvoir traiter cette erreur avec les outils disponibles dans SSIS. Pour ce faire il faut recupérer la valeur de retour d'un package au moyen de la propriété ExecValueVariable qu'il faut binder à une variable. Cette propriété se trouve au niveau de la tache d'exécution d'un package. Cela permet par la suite de créer des contraintes de flow basées sur cette valeur.

Bonne journée

[bridaine]

Merci beaucoup pour toutes ces précisions :

Voici le verdict de l'inspection :

ProtectionLevel = EncryptSensitiveWithUserKey (si ça peut être un problème, on va aviser)

Mais il y a autre chose qui me chiffonne, le serveur :

Computer Creator Name = A01WS-P03030 (c'est mon PC, pas le Serveur où se trouve l'application client)

Si c'était le Serveur de la DB, ça serait : A91SV9201SQL et c'est là que se trouve l'Agent SQL Server ! Cela doit jouer, non ?

Car à la création du step, il a été impossible de faire apparaître ce nom de serveur (et pour cause) et c'est A01WS-P03030 qui est apparu...

Tenons-nous là le noeud du problème ?

[Ptit_Dje]

EncryptSensitiveWithUserKey va encrypter les données sensibles c'est à dire les infos de connection principalement.

Encrypts the entire package by using keys based on the current user. Only the same user using the same profile can load the package. If a different user opens the package, the sensitive information is replaced with blanks. DPAPI is used for this encryption.

Ici, j'ai eu le cas ou j'utilisais le même domaine accompte pour développer des packages SSIS, j'ai changer de laptop entre temps, je n'avais plus accès à toutes les infos des packages... Heureusement mon précédent laptop était utilisé par un collègue, je m'y suis loggué et j'ai pu changer le mode de protection des packages!

Je vous conseille d'utiliser un mode de protection par mot de passe, c'est plus simple d'après moi.
Au moment du scheduling dans l'agent, il vous le demandera.

Bonne journée