Sto utilizzando SQL Server Agent per pianificare anche attività non di database: è una cattiva idea?

Dato che sono un DBA (e in molti casi, l'amministratore di fatto), SQL Server è installato praticamente su tutti i server con cui devo lavorare regolarmente. Di recente mi sono reso conto che sto usando SQL Agent come pianificatore di lavori in quasi tutti i casi, piuttosto che l'utilità di pianificazione di Windows nativa.

Dal mio punto di vista, l'agente SQL presenta numerosi vantaggi rispetto all'utilità di pianificazione di Windows nativa:

• Avvio / arresto / monitoraggio remoto delle attività
• Pianificazioni condivise (piuttosto che ciascuna attività da sola)
• Passaggi multipli e flusso di controllo
• Diversi tipi di attività
• Avvisi in caso di errore / completamento
• Può essere configurato per agire come utenti diversi
• Messaggi di errore (moderatamente) descrittivi, anziché solo un codice di errore

Tuttavia, non posso sfuggire alla sensazione che questa sia una cattiva pratica: l'agente SQL dovrebbe essere riservato solo alle attività relative al database e dovrei lasciare attività a livello di sistema operativo nell'Utilità di pianificazione di Windows, nonostante non mi piaccia la sua usabilità.

Va bene fare affidamento su SQL Agent in questo modo? In caso contrario, dovrei prendere in considerazione un programmatore di attività di Windows di terze parti per ottenere alcune delle funzionalità che sto cercando?

Personalmente penso che il più grande avvertimento sarebbe la difficoltà a mantenere organizzato l'elenco dei lavori. Per quanto ne so, non è possibile creare cartelle per organizzare i lavori, quindi un gran numero sarebbe ingombrante. Non ne sono sicuro al 100%, dal momento che nessuno dei miei server ha più di una dozzina di lavori. L'utilità di pianificazione di Server 2008 e successive consente un'organizzazione molto più semplice, IMO e in generale ha funzionalità molto migliori rispetto alle versioni precedenti. Sono sicuro che le app di terze parti svolgono un lavoro ancora migliore. Vorrei piangere se dovessi usare l'utilità di pianificazione di Server 2003 o at.exe.

Il secondo avvertimento che mi viene in mente sarebbe potenzialmente caricare troppo sul server SQL. L'agente è un piccolo programma, ma l'esecuzione di un'attività lunga o complessa potrebbe facilmente consumare molte risorse. Tali risorse non sarebbero disponibili per il motore SQL. Poiché il motore SQL è programmato per occupare circa l'80% della memoria di sistema disponibile, questo potrebbe essere un problema.

In terzo luogo, il backup potrebbe essere un problema. Non sarà necessario solo il backup del filesystem, ma anche il database msdb per consentire il ripristino dei lavori (o utilizzare qualcosa per eseguire lo script delle attività su un file di testo). Ciò aggiunge un livello di complessità al ripristino di emergenza.

Infine, non vorrai trovarti in una posizione in cui stai pagando una licenza di SQL Server solo per eseguire SQL Server Agent. Se il database viene rimosso, sarà necessario sviluppare un piano per la migrazione da SQL Server Agent.

Nel mio lavoro precedente ho fatto esattamente questo, principalmente perché i lavori erano tutti eseguiti dal nostro cluster principale centrale, che era il server più visibile. Ho potuto vedere tutte le nostre attività pianificate in un unico posto invece di dover andare a controllare le cose della riga di comando su un gruppo di server.

Mentre questo è in gran parte soggettivo (e sarà difficile ottenere una risposta "corretta" in questo formato), non penso che ci sia qualcosa di intrinsecamente sbagliato in questo approccio diverso da quello che diventa un singolo punto di fallimento.

Ciò potrebbe non essere rilevante se tutte le attività interagiscono con o dipendono dal server di database attivo e dai servizi di SQL Server in esecuzione (nel nostro caso, è successo).

Oh, e devi aggiungere la gestione degli errori per i casi in cui il server in cui l'attività tenta di eseguire non è attivo, cosa che non dovresti fare se l'attività fosse impostata su quel server.

Vorrei ~ probabilmente ~ prendere SQL Agent tramite il task manager di Windows ... ovviamente per le attività relative al database.

Se riesci a programmare o hai persone in grado di programmare, puoi fare un bel po 'con le app della console e inserirle in un creatore di servizi come TopShelf (http://topshelf-project.com/) Questo può essere un economico / hack facile per ottenere un piccolo disaccoppiamento da SQL Agent per tutto e iniziare a darti anche un livello per l'accodamento se sei a quel punto.

Personalmente, sembri preoccuparti abbastanza di questo, oltre a conoscere abbastanza dei tuoi gotchas che penso che starai bene. Sono le persone a cui non importa / che mi preoccupano davvero. Non ho dubbi sul fatto che valuterai le tue soluzioni a intervalli ragionevoli e agirai di conseguenza.

Un'altra opzione è quella di creare una tabella per le attività pianificate con una procedura memorizzata per aggiornare una tabella delle code dei messaggi da essa. Quindi SQL Server Agent chiamava la procedura memorizzata ogni tanto per creare messaggi e aggiornare lo stato dell'attività. Altri sistemi interrogerebbero la tabella delle code dei messaggi tramite una connessione SQL o un livello API Web come JSON.