Un buon modo per chiamare più processi SQL Server Agent in sequenza da un processo principale?

Ho diversi lavori di SQL Server Agent che dovrebbero essere eseguiti in sequenza. Per mantenere una buona panoramica dei lavori che devono essere eseguiti, ho creato un lavoro principale che chiama gli altri lavori con una chiamata a EXEC msdb.dbo.sp_start_job N'TEST1'. Il processo sp_start_jobtermina all'istante (Job Step 1), ma poi desidero che il mio lavoro principale attenda il completamento del lavoro TEST1prima di chiamare il lavoro successivo.

Quindi ho scritto questo piccolo script che inizia l'esecuzione subito dopo che il lavoro è stato chiamato (Job Step 2) e forza il lavoro principale ad attendere fino al termine del lavoro secondario:

WHILE 1 = 1
  BEGIN
    WAITFOR DELAY '00:05:00.000';

    SELECT *
    INTO   #jobs
    FROM   OPENROWSET('SQLNCLI', 'Server=TESTSERVER;Trusted_Connection=yes;',
           'EXEC msdb.dbo.sp_help_job @job_name = N''TEST1'',
           @execution_status = 0, @job_aspect = N''JOB''');

    IF NOT (EXISTS (SELECT top 1 * FROM #jobs))
      BEGIN
        BREAK
      END;

    DROP TABLE #jobs;

  END;

Funziona abbastanza bene. Ma ho avuto la sensazione che le soluzioni più intelligenti e / o più sicure ( WHILE 1 = 1?) Dovrebbero essere possibili.

Sono curioso di sapere le seguenti cose, spero che tu possa fornirmi alcune intuizioni:

• Quali sono i problemi con questo approccio?
• Puoi suggerire un modo migliore per farlo?

(Ho pubblicato prima questa domanda su StackOverflow , perché mi stavo concentrando sul miglioramento del codice. Ancora valido. Ma la mia ipotesi è che le persone qui in generale avranno cose più intelligenti da dire sul perché non dovrei provare a farlo nel modo in cui ' lo sto facendo ora, o fornire buone alternative.)

EDIT (25 luglio)
A quanto pare non c'è molto di sbagliato nel mio script, in base al basso numero di risposte che evidenziano problemi con esso :-) L'alternativa a questo tipo di script sembra essere l'uso di uno strumento progettato per questi attività (come SQL Sentry Event Manager o ...) - o per scrivere tale strumento da soli. Non compreremo uno strumento simile nella mia attuale azienda, quindi per ora mi limiterò a seguire la sceneggiatura.

Disclaimer: lavoro per SQL Sentry.

Il nostro prodotto SQL Sentry Event Manager ha una struttura costruita proprio per questo: incatenare i lavori e disporli in vari ordini di flusso di lavoro.

Ho iniziato a utilizzare SQL Sentry anni fa, prima di entrare a far parte dell'azienda, per fare esattamente questo. Quello che volevo era un modo per avviare un processo di ripristino sul nostro server di prova immediatamente dopo il completamento del backup sulla produzione.

Ciò che avevo originariamente implementato era solo un buffer sostanziale tra l'ora di inizio del processo di backup e l'ora di inizio del ripristino. Questo non era esattamente infallibile; poiché i tempi di backup sono variati, il buffer spesso ci ha lasciato del tempo sprecato in cui un ripristino non era iniziato anche se avrebbe potuto. E a volte il buffer non era abbastanza.

Quello che ho implementato in seguito è stato simile a quello che hai: ho scritto un lavoro sul server di prova che è iniziato poco dopo il backup pianificato e ho continuato il polling per vedere quando il lavoro era finito. Ciò è stato successivamente modificato per avere solo un secondo passaggio nel processo di backup che ha aggiornato una tabella sul server di prova. Non molto diverso, tranne per il fatto che il processo di ripristino doveva solo guardare una tabella localmente invece di monitorare la cronologia dei processi in remoto. Ripensandoci, questo avrebbe potuto essere un fattore scatenante su quella tabella che chiamava, sp_start_jobquindi il lavoro non doveva essere eseguito ogni n minuti (o essere programmato).

La soluzione finale era quella di concatenare i lavori insieme ... al termine del backup sul server A, Event Manager avvia il processo di ripristino sul server B. E se esisteva un terzo lavoro e un quarto lavoro o una logica condizionale basata su cosa fare quando un lavoro fallisce vs. ha successo, ecc., tutto ciò può essere preso in considerazione. Il designer del flusso di lavoro ti ricorderà un bel po 'di SSIS:

La meccanica di base di ciò che sto descrivendo non è la chirurgia missilistica, ovviamente. Puoi scrivere tu stesso questo tipo di incatenamento se ti sedessi e lo facessi. Ti sto solo fornendo un'alternativa dove non devi.

Il problema principale con il tuo approccio è che devi fare continuamente il giro finché non accade qualcosa (che potrebbe essere terribilmente lungo o addirittura mai) e che non sembra proprio giusto. Ecco perché suppongo che tu stia facendo la domanda.

Quindi, che ne dici di utilizzare un approccio basato sui dati al tuo problema? Ad esempio, creare una tabella di "controllo" in cui ogni lavoro scrive quando inizia e termina:

Nome lavoro | Ora di inizio | Tempo scaduto
--------- + ------------------- + ------------------
Test1 2012-07-26 07:30 2012-07-26 07:35

Creare una tabella di "elaborazione" che elenca tutti i lavori e l'ordine in cui devono essere eseguiti:

Nome lavoro | Esegui ordine
--------- --------- +
Test1 | 1
Test2 | 2
Test3 | 3

Creare un trigger di inserimento nella tabella di controllo, in modo che quando un processo viene completato e viene inserito il record di controllo, il trigger esegue una query sulla tabella di elaborazione per il processo successivo (per Ordine di esecuzione) e quindi lo avvia.

I vantaggi di questo approccio sono:

1. È abbastanza semplice da sviluppare e mantenere.
2. Offre la possibilità di aggiungere nuovi lavori o modificare l'ordine dei lavori esistenti tramite la tabella di elaborazione senza dover modificare una riga di codice.
3. La tabella di audit offre una certa visibilità su quando sono avvenute le cose.
4. Non spreca i cicli della CPU. Il grilletto sparerà solo quando è successo qualcosa.
5. Si sente 😉 destra

HTH