J'utilise l'Agent SQL Server pour planifier même des tâches hors base de données - est-ce une mauvaise idée?

Étant donné que je suis un administrateur de base de données (et dans de nombreux cas, l'administrateur système de facto), SQL Server est installé sur à peu près tous les serveurs avec lesquels je dois travailler régulièrement. J'ai réalisé récemment que j'utilisais l'agent SQL comme planificateur de travaux dans presque tous les cas, plutôt que le planificateur de tâches Windows natif.

De mon point de vue, l'Agent SQL présente un certain nombre d'avantages par rapport au Planificateur de tâches Windows natif:

• Démarrage / arrêt / surveillance à distance (depuis mon poste de travail) des tâches
• Horaires partagés (plutôt que chaque tâche seule)
• Étapes multiples et contrôle du flux
• Différents types de tâches
• Alertes en cas d'échec / achèvement
• Peut être configuré pour agir en tant qu'utilisateurs différents
• (Modérément) des messages d'erreur descriptifs, plutôt qu'un simple code d'erreur

Cependant, je ne peux pas échapper au sentiment qu'il s'agit d'une mauvaise pratique - l'agent SQL doit être réservé aux tâches liées à la base de données uniquement et je dois laisser les tâches au niveau du système d'exploitation s'exécuter dans le planificateur de tâches Windows, malgré mon aversion pour son utilisation.

Est-il correct de s'appuyer sur l'Agent SQL de cette manière? Sinon, dois-je envisager un planificateur de tâches Windows tiers pour obtenir certaines des fonctionnalités que je recherche?

Personnellement, je pense que la plus grande mise en garde serait la difficulté à organiser la liste des emplois. Pour autant que je sache, vous ne pouvez pas créer de dossiers pour organiser les travaux, donc un grand nombre serait lourd. Je ne suis pas sûr à 100% de cela, car aucun de mes serveurs n'a plus d'une douzaine de tâches. Le Planificateur de tâches de Server 2008 et versions ultérieures permet une organisation beaucoup plus facile, IMO et, en général, a de bien meilleures fonctionnalités que les versions précédentes. Je suis sûr que les applications tierces font encore mieux. Je pleurerais si je devais utiliser le planificateur de tâches de Server 2003 ou at.exe.

La deuxième mise en garde à laquelle je peux penser serait potentiellement de mettre trop de charge sur le serveur SQL. L'agent est un petit programme, mais l'exécution d'une tâche longue ou complexe peut facilement consommer beaucoup de ressources. Ces ressources ne seraient pas disponibles pour le moteur SQL. Étant donné que le moteur SQL est programmé pour prendre environ 80% de la mémoire système disponible, cela pourrait être un problème.

Troisièmement, la sauvegarde peut être un problème. Vous devrez non seulement sauvegarder le système de fichiers, mais aussi la base de données msdb pour permettre la récupération des travaux (ou utiliser quelque chose pour scripter les tâches dans un fichier texte). Cela ajoute une couche de complexité à la reprise après sinistre.

Enfin, vous ne voudriez pas être dans une position où vous payez pour une licence SQL Server juste pour exécuter SQL Server Agent. Si la base de données est mise hors service, vous devrez développer un plan de migration hors de l'Agent SQL Server.

Lors de mon travail précédent, j'ai fait exactement cela, principalement parce que les travaux étaient tous exécutés à partir de notre cluster principal central, qui était le serveur le plus visible. Je pouvais voir toutes nos tâches planifiées en un seul endroit au lieu d'avoir à vérifier des choses en ligne de commande sur un tas de serveurs.

Bien que cela soit largement subjectif (et il sera difficile d'obtenir une réponse «correcte» dans ce format), je ne pense pas qu'il y ait quelque chose de fondamentalement mauvais avec cette approche, sinon qu'elle devient un seul point d'échec.

Cela peut ne pas être pertinent si toutes les tâches interagissent avec ou dépendent du serveur de base de données en cours d'exécution et des services SQL Server en cours d'exécution (dans notre cas, c'est le cas).

Oh, et vous devez ajouter une gestion des erreurs pour les cas où le serveur sur lequel la tâche essaie de s'exécuter n'est pas opérationnel - quelque chose que vous n'auriez pas à faire si la tâche était configurée sur ce serveur.

Je prendrais ~ probablement ~ SQL Agent sur le gestionnaire de tâches Windows ... évidemment pour les tâches liées à la base de données.

Si vous pouvez coder ou avoir des gens qui peuvent coder, vous pouvez faire beaucoup avec les applications de console et les encapsuler dans un créateur de service comme TopShelf (http://topshelf-project.com/). Cela peut être un bon marché / pirater facilement pour obtenir un petit découplage de l'Agent SQL pour tout et commencer à vous donner également une couche pour la file d'attente si vous êtes à ce stade.

Personnellement, vous semblez suffisamment vous soucier de cela et connaître suffisamment vos pièges pour que je pense que vous irez bien. Ce sont les gens qui s'en moquent / savent que je m'inquiète vraiment. Je suis convaincu que vous évaluerez vos solutions à intervalles raisonnables et agirez en conséquence.

Une autre option consiste à créer une table pour les tâches planifiées avec une procédure stockée pour mettre à jour une table de file d'attente de messages à partir de celle-ci. L'agent SQL Server appelle ensuite la procédure stockée de temps en temps pour créer des messages et mettre à jour l'état de la tâche. D'autres systèmes interrogent la table de file d'attente de messages via une connexion SQL ou une couche d'API Web en tant que JSON.