Estoy usando el Agente SQL Server para programar incluso tareas que no son de la base de datos. ¿Es una mala idea?

Como soy un DBA (y en muchos casos, el administrador de sistemas de facto), SQL Server está instalado en casi todos los servidores con los que tengo que trabajar regularmente. Recientemente me di cuenta de que he estado usando el Agente SQL como programador de trabajos en casi todos los casos, en lugar del Programador de tareas nativo de Windows.

Desde mi perspectiva, el Agente SQL tiene una serie de ventajas sobre el Programador de tareas nativo de Windows:

• Inicio / parada / supervisión remota de tareas (desde mi estación de trabajo)
• Horarios compartidos (en lugar de cada tarea por sí sola)
• Múltiples pasos y control de flujo
• Diferentes tipos de tareas.
• Alertas sobre falla / finalización
• Se puede configurar para actuar como diferentes usuarios
• (Moderadamente) mensajes de error descriptivos, en lugar de solo un código de error

Sin embargo, no puedo escapar de la sensación de que esta es una mala práctica: el Agente SQL debe reservarse solo para tareas relacionadas con la base de datos, y debo dejar las tareas a nivel del sistema operativo ejecutándose en el Programador de tareas de Windows, a pesar de mi disgusto por su facilidad de uso.

¿Está bien confiar en el Agente SQL de esta manera? Si no, ¿debería considerar un programador de tareas de Windows de terceros para obtener algunas de las funciones que estoy buscando?

Personalmente, creo que la mayor advertencia sería la dificultad de mantener organizada la lista de trabajos. Hasta donde sé, no puede crear carpetas para organizar los trabajos, por lo que un gran número sería engorroso. Sin embargo, no estoy 100% seguro de esto, ya que ninguno de mis servidores tiene más de una docena de trabajos. El Programador de tareas de Server 2008 y posterior permite una organización mucho más fácil, IMO, y en general tiene una funcionalidad mucho mejor que las versiones anteriores. Estoy seguro de que las aplicaciones de terceros hacen un trabajo aún mejor. Lloraría si tuviera que usar el programador de tareas de Server 2003 o at.exe.

La segunda advertencia que se me ocurre sería potencialmente poner demasiada carga en el servidor SQL. El Agente es un programa pequeño, pero ejecutar una tarea larga o compleja podría consumir fácilmente muchos recursos. Esos recursos no estarían disponibles para el motor SQL. Dado que el motor SQL está programado para tomar aproximadamente el 80% de la memoria disponible del sistema, esto podría ser un problema.

Tercero, la copia de seguridad puede ser un problema. No solo necesitará hacer una copia de seguridad del sistema de archivos, sino también la base de datos msdb para permitir la recuperación de los trabajos (o usar algo para escribir las tareas en un archivo de texto). Esto agrega una capa de complejidad a la recuperación ante desastres.

Finalmente, no querrá estar en una posición en la que esté pagando una licencia de SQL Server solo para ejecutar el Agente SQL Server. Si la base de datos se da de baja, deberá desarrollar un plan para migrar el Agente SQL Server.

En mi trabajo anterior hice exactamente esto, principalmente porque todos los trabajos se ejecutaron desde nuestro clúster primario central, que era el servidor más visible. Pude ver todas nuestras tareas programadas en un solo lugar en lugar de tener que ir a verificar las cosas de la línea de comandos en un montón de servidores.

Si bien esto es en gran parte subjetivo (y va a ser difícil obtener una respuesta "correcta" en este formato), no creo que haya nada intrínsecamente incorrecto con este enfoque, aparte de que se convierta en un único punto de falla.

Eso podría no ser relevante si todas las tareas interactúan o dependen del servidor de la base de datos que está funcionando y los servicios de SQL Server en ejecución (en nuestro caso, lo hicieron).

Ah, y debe agregar el manejo de errores para los casos en que el servidor donde la tarea intenta ejecutarse no está activo, algo que no tendría que hacer si la tarea se configurara en ese servidor.

Yo ~ probablemente ~ tomaría el Agente SQL sobre el administrador de tareas de Windows ... obviamente para tareas relacionadas con la base de datos.

Si puede codificar, o tener personas que puedan codificar, puede hacer bastante con las aplicaciones de consola y envolverlas en un creador de servicios como TopShelf (http://topshelf-project.com/). Esto puede ser barato / Hack fácil para obtener un pequeño desacoplamiento del Agente SQL para todo y comenzar a darle también una capa para hacer cola si está en ese punto.

Personalmente, parece que te preocupas lo suficiente por esto, además de saber lo suficiente de tus problemas que creo que estarás bien. Son las personas a las que no les importa / saben lo que realmente me preocupa. No tengo dudas de que evaluará sus soluciones a intervalos razonables y actuará en consecuencia.

Otra opción es crear una tabla para tareas programadas con un procedimiento almacenado para actualizar una tabla de colas de mensajes. Luego, el Agente SQL Server llamaba al procedimiento almacenado de vez en cuando para crear mensajes y actualizar el estado de la tarea. Otros sistemas consultarían la tabla de la cola de mensajes a través de una conexión SQL o una capa API web como JSON.