Jobs SQL Server depuis autre table que msdb

Bonjour à tous,

J'ai 2 questions principales à vous poser (4 en tout). Je pense que c'est le Ba-ba, mais je commence aujourd'hui avec MS SQL et je ne trouve pas toutes les réponses à mes questions sur le site de Microsoft. Merci par avance pour vos réponses éventuelles.

Je travaille sur une base de données BDD001 qui contient un répliqua de la base système msdb d'un système distant. La structure de ma base locale est donc:
Databases -> BDD001 -> Tables -> System Tables -> <et ici les tables de msdb>.

Je m'intéresse exclusivement aux jobs de cette base.

[Question 1]
Je dois lancer les jobs de ce répliqua, si possible depuis cette nouvelle base. Mais il me semble que ce n'est pas possible, ces jobs doivent être 'absolument' contenus dans une base nommée msdb pour pouvoir être lancés, c'est juste ?

[Question 2]
S'il me faut inscrire ces jobs dans ma base msdb locale, une copie 1 à 1 des enregistrements (de sysjobs, sysjobshedules, etc.) est-elle possible ?
- Si non, dois-je passer par les Transact-SQL dédiés (create_job, etc), donc créer un script qui recrée tous ces jobs.
- Si oui, la recopie des tables suivantes est-elle suffisante pour recréer tous mes jobs: dbo.sysjobs, dbo.sysjobschedules, dbo.sysjobservers, dbo.sysjobsteps. Ou alors y a-t-il une autre table importante concernant les jobs ?

Je vous remercie beaucoup pour toute réponse, je suis un peu perdu dans ce fonctionnement pour le moment.

[Re]Bonjour,

il me vient une idée, peut être est-ce que quelqu'un l'a déjà utilisée ...

Pour appeler un Job on peut théoriquement l'appeler depuis la procédure stockée [sp_start_job].

Lorsqu'on édite le code de cette procédure, on se rend compte qu'elle référence en dur la table msdb. Il me vient donc l'idée de la dupliquer et lui donner un autre nom plus spécifique de manière à ce qu'elle pointe sur ma base BDD001 et non plus msdb. Seul hic, cette procédure en appelle d'autres et il faudrait donc, en cas de référencement par ces dernières de msdb, les dupliquer à leur tour pour qu'elles pointent vers ma base.

Du coup, je me dis que ces procédures dupliquées pourraient contenir un paramètre supplémentaire: la base à utiliser, lequel paramètre serait donc passé lors des appels type:

Code:

---

1 2 3 4

IF (NOT EXISTS (SELECT * FROM @param_base.dbo.my_sysjobservers WHERE (job_id = @job_id)))

---

Est-ce que cela reste possible, ou bien vais-je perdre mon temps à le faire ?

Je n'ai que 6 jobs à appeler pour le moment, la liste devrait s'agrandir, mais pour des raisons de maintenance il n'est pas souhaitable d'installer ces jobs là dans la table msdb actuelle ... d'où ma recherche.

Merci pour tout commentaire éventuel.

Bonjour,

Citation:

---

Est-ce que cela reste possible, ou bien vais-je perdre mon temps à le faire ?

---

C'est possible bien sûr même si à mon avis c'est une vaste entreprise, mais je ne pense pas qu'ensuite vous pourrez les faire appeler par l'Agent SQL Server :?

Je n'ai pas de d'édition Developer pour tester cela, mais j'essaierai deux solutions :
- la première, faire un backup de MSDB sur le serveur source, le restaurer sur le serveur cible sous un autre nom, et alimenter les tables de MSDB, mais cela me semble long ...
- la deuxième, créer une procédure stockée d'assembly enregistrée sur le serveur cible qui scripte les jobs de votre serveur source et les joue sur le serveur cible... à voir aussi :s

@++ ;)

Bonjour,
c'est bien ce qui me semblait, le service Windows ne trouvera pas ces jobs même si tous les scripts les référencent, sans compter l'ampleur de la tâche oui ! (une longue entreprise) ...

Vous proposez donc que je code un script qui se charge d'effectuer les sp_add_job, sp_add_jobsteps... et finalement les démarre, donc qui recrée ces jobs de ma base dans la base msdb ?

LE souci, c'est que ma base actuelle de travail est une base SQL Server 6.0 ou 6.5 et donc je doute pouvoir coder un assembly en C# (pas implémenté avant SQL Server 2005 d'après ce que j'ai lu) ... donc il me faut trouver une doc SQL Server 6.0 qui explique la création de jobs en Transact-SQL, si cela existait déjà :)

Je vous remercie pour votre réponse. Ca fait avancer le schmilblick.