Estou usando o SQL Server Agent para agendar até tarefas que não são do banco de dados - isso é uma má idéia?

Como sou um DBA (e, em muitos casos, o administrador de sistemas de fato), o SQL Server é instalado em praticamente todos os servidores com os quais tenho que trabalhar regularmente. Percebi recentemente que tenho usado o SQL Agent como agendador de tarefas em praticamente todos os casos, em vez do agendador de tarefas nativo do Windows.

Na minha perspectiva, o SQL Agent possui várias vantagens sobre o Windows Task Scheduler nativo:

• Início / parada / monitoramento remoto de tarefas (da minha estação de trabalho)
• Agendas compartilhadas (em vez de cada tarefa por conta própria)
• Várias etapas e fluxo de controle
• Diferentes tipos de tarefas
• Alertas sobre falha / conclusão
• Pode ser configurado para atuar como usuários diferentes
• Mensagens de erro (moderadamente) descritivas, em vez de apenas um código de erro

No entanto, não posso deixar de pensar que isso é uma prática ruim - o SQL Agent deve ser reservado apenas para tarefas relacionadas ao banco de dados e devo deixar as tarefas no nível do SO em execução no Agendador de Tarefas do Windows, apesar de não gostar de sua usabilidade.

Tudo bem contar com o SQL Agent dessa maneira? Caso contrário, devo considerar um agendador de tarefas do Windows de terceiros para obter algumas das funcionalidades que estou procurando?

Pessoalmente, acho que a maior advertência seria a dificuldade de manter a lista de empregos organizada. Tanto quanto sei, você não pode criar pastas para organizar os trabalhos, portanto, um grande número seria complicado. Não tenho 100% de certeza disso, já que nenhum dos meus servidores tem mais de uma dúzia de empregos. O Server 2008 e o Agendador de tarefas posteriores permitem uma organização muito mais fácil, o IMO e, em geral, têm uma funcionalidade muito melhor que as versões anteriores. Tenho certeza de que aplicativos de terceiros fazem um trabalho ainda melhor. Eu choraria se tivesse que usar o agendador de tarefas do Server 2003 ou at.exe.

A segunda ressalva em que posso pensar seria colocar potencialmente muita carga no servidor SQL. O agente é um programa pequeno, mas a execução de uma tarefa longa ou complexa pode consumir facilmente muitos recursos. Esses recursos não estariam disponíveis para o mecanismo SQL. Como o mecanismo SQL está programado para consumir cerca de 80% da memória do sistema disponível, isso pode ser um problema.

Terceiro, o backup pode ser um problema. Você não precisará apenas fazer backup do sistema de arquivos, mas também do banco de dados msdb para permitir a recuperação dos trabalhos (ou usar algo para criar scripts das tarefas em um arquivo de texto). Isso adiciona uma camada de complexidade à recuperação de desastres.

Finalmente, você não gostaria de estar em uma posição em que está pagando por uma licença do SQL Server apenas para executar o SQL Server Agent. Se o banco de dados for descomissionado, você precisará desenvolver um plano para migrar do SQL Server Agent.

No meu trabalho anterior, fiz exatamente isso, principalmente porque os trabalhos foram executados em nosso cluster principal central, que era o servidor mais visível. Pude ver todas as nossas tarefas agendadas em um só lugar, em vez de precisar verificar as coisas da linha de comando em vários servidores.

Embora isso seja amplamente subjetivo (e será difícil obter uma resposta "correta" nesse formato), não acho que exista algo inerentemente errado nessa abordagem, a não ser que ela se torne um ponto único de falha.

Isso pode não ser relevante se todas as tarefas interagirem com ou dependerem do servidor de banco de dados estar ativo e dos serviços do SQL Server em execução (no nosso caso, sim).

Ah, e você precisa adicionar tratamento de erros nos casos em que o servidor em que a tarefa tenta executar não está ativo - algo que você não precisaria fazer se a tarefa estivesse configurada nesse servidor.

Eu provavelmente pegaria o SQL Agent no gerenciador de tarefas do Windows ... obviamente para tarefas relacionadas ao banco de dados.

Se você pode codificar ou ter pessoas que podem codificar, você pode fazer bastante com aplicativos de console e envolvê-los em um criador de serviços como o TopShelf (http://topshelf-project.com/) Isso pode ser um preço baixo / hack fácil para obter um pouco de dissociação do SQL Agent para tudo e começar a também fornecer uma camada para enfileiramento, se você estiver nesse ponto.

Pessoalmente, você parece se importar o suficiente com isso, além de conhecer o suficiente de suas dicas que acho que ficará bem. São as pessoas que não se importam / sabem que realmente me preocupo. Não tenho dúvidas de que você avaliará suas soluções em intervalos razoáveis ​​e agirá de acordo.

Outra opção é criar uma tabela para tarefas agendadas com um procedimento armazenado para atualizar uma tabela da fila de mensagens. Em seguida, o SQL Server Agent chamava o procedimento armazenado de vez em quando para criar mensagens e atualizar o status da tarefa. Outros sistemas consultariam a tabela da fila de mensagens por meio de uma conexão SQL ou uma camada de API da web como JSON.