Mucho hemos hablado en este blog de tareas de mantenimiento que programamos en Jobs del agente de SQL, con algún vídeo incluso. También hemos hablado de las alertas. Sin embargo no habíamos dedicado un artículo al Agente de SQL en general. Aunque no vamos a negar que son la piedra angular de este servicio, el agente es bastante más que solo los jobs, y eso es lo que la gran mayoría de los usuarios y DBAs desconocen, sobre todo los menos experimentados.
Jobs del agente
Como ya hemos dicho, los jobs son la principal función del agente de SQL y prácticamente todo lo demás gira en torno a ellos. Pero, ¿qué son los jobs?. Los jobs o trabajos del agente de SQL Server son tareas programadas que podremos crear en el agente de SQL Server para que las ejecute en un horario o en respuesta a un evento específico. Podemos incluir en un job uno o más pasos, cada uno de los cuales realizará una acción específica.
Podemos utilizar jobs para realizar una variedad de funciones, como la ejecución de procedimientos almacenados, ejecución de consultas SQL o para tareas de mantenimiento. Pero no solo scripts de SQL, los jobs del agente de SQL Server también admiten comandos cmd o powershell o ejecuciones de SSIS o SSAS. Existen también tipos de jobs específicos para la replicación.
Para los usuarios más avanzados, estos jobs los podemos encontrar en la tabla sysjobs del esquema dbo de la base de datos msdb. En esta misma base de datos y esquema podemos encontrar los pasos de estos jobs en la tabla sysjobstesp y las programaciones en la tabla sysschedules. Esta última tabla se relaciona con la de jobs a través de la tabla sysjobsschedules. Completan este grupo de tablas sysjobactivity, sysjobhistory y sysjobstepslogs. Con estas tablas podemos generar nuestras propias consultas para visualizar todo lo que necesitemos.
Configuración de los jobs del Agente
Las capacidades de configuración de los jobs de SQL son tantas que rara vez he visto a usuarios sacarles todo el provecho. En ocasiones directamente no se aprovechan. Por un lado tenemos las configuraciones propias del agente de las que hablaremos más adelante, por otro las de los jobs y por último las configuraciones particulares de cada paso de los jobs.
En las configuraciones de los jobs podremos encontrar las relativas a su información general, sus pasos y programaciones además de alertas, notificaciones y servidores donde se va a ejecutar. Porque sí, el agente de SQL tiene la capacidad de actuar sobre uno o varios servidores SQL de nuestra red.
Los pasos también tienen sus configuraciones específicas donde, además de configurar el propio paso, podremos definir su comportamiento al terminar con éxito o error, sus opciones de logado (a disco o tabla) y si deseamos que se ejecute con una cuenta específica.
Operadores y proxies del Agente
En lo tocante a los, podremos encontrar en el agente Operadores o Proxies (proxys), cada uno de ellos objetos que van a realizar una función distinta.
Por un lado, los operadores son destinatarios de los avisos del agente. Definiremos su nombre y su dirección de correo. También podremos configurar un pager email para estos operadores, si es que alguien sigue usando los antiguos “buscas” o “beepers” en pleno año 2024. Por último podremos definir un horario para que solo puedan recibir alertas en las horas establecidas.
Por otro lado, podemos configurar proxies, un objeto totalmente distinto al que asociaremos una credencial de una cuenta para luego poder configurar los pasos de los jobs para que se ejecuten bajo el contexto de seguridad de esa cuenta de AD. Los proxies se hacen necesarios para ejecutar tareas de SSIS, CMD o PowerShell que impliquen recursos ajenos a SQL Server como archivos del servidor o de la red.
Alertas
En este apartado no nos vamos a extender mucho, ya le dedicamos un artículo entero a esta opción donde os compartí como hago yo para configurarlo. En resumen, el Agente SQL Server lee el log de SQL y compara los eventos con las alertas definidas. Cuando el Agente SQL Server encuentra una coincidencia, activa una alerta, que es una respuesta automatizada a un evento y puede ser la ejecución de un job, el envió de un mail a un operador o ambas. Las alertas pueden responder a eventos de SQL Server, condiciones de rendimiento de SQL Server y eventos de Instrumental de administración de Windows (WMI).
Para definir una alerta, debes especificar: el nombre de la alerta, el evento o condición de rendimiento que desencadena la alerta, y la acción que el Agente SQL Server realiza como respuesta al evento o condición de rendimiento.
Configuración del agente
Como os he adelantado antes, el agente dispone de una configuración general que es importante que revisemos y adaptemos a nuestras necesidades. Por un lado vamos a poder configurar desde el comportamiento frente a un fallo que detenga el servicio hasta el reenvío de logs a un servidor distinto cuando el agente forme parte de un grupo de servidores.
Sin embargo, las configuraciones más importantes para mi son las que tienen que ver con habilitar el uso de dbmail para poder responder a alertas o notificaciones de los jobs. Es importante también que configuremos un fail-safe operator. Este es un operador que va a recibir las notificaciones en caso de que estas no puedan ser entregadas a los operadores designados en las notificaciones o las alertas por un error. Este operador solo recibirá las alertas como última opción y solo puede ser definido por un usuario sysadmin.
Para terminar con las configuraciones del agente de SQL que me parecen importantes tenemos las relativas al historial de ejecuciones de los jobs. Aquí vamos a poder definir tanto el máximo de historiales de un job como el general que vamos a admitir. Esto es importante porque una mala configuración puede hacer que perdamos información o que se nos llegue a llenar el disco. Cualquiera de los dos extremos no es aceptable.
Permisos sobre el agente
Llegamos a uno de los puntos que más controversia generan, aquí tenemos el elefante en la habitación y vamos a soltarlo ya. Los permisos del agente se asignan asignando a los usuarios a roles fijos de la base de datos msdb. Son permisos cerrados sobre los que no vamos a poder actuar y es necesario que conozcamos sus particularidades y limitaciones. Los roles que nos vamos a encontrar son:
- SQLAgentUserRole: Es el rol con menos privilegios, solo va a tener permisos sobre los operadores (sólo visualización) y sobre los jobs solo va a poder actuar sobre los que le pertenecen y podrá verlos así como editarlos, habilitarlos o deshabilitarlos e iniciarlos y detenerlos. En caso de estar ante un grupo de servidores solo va a tener acceso a los jobs locales y siempre solo los que estén a su nombre.
- SQLAgentReaderRole: Va un paso más allá que el anterior y además de todos los permisos anteriores permite listar los objetos como operadores, proxies y alertas. También verá todos los jobs así como su historial de ejecución aunque solo podrá editar, iniciar o detener los de su pertenencia.
- SQLAgentOperatorRole: Es el más avanzado de los roles del agente e incluye, además de todo lo anterior, la posibilidad de ver las propiedades de los operadores y los proxies. Los usuarios de este rol no tienen tampoco permisos de modificación sobre ningún job que no sea de su propiedad. Esto queda limitado en exclusiva a los usuarios sysadmin. Lo único que van a poder hacer sobre los jobs que no sean de su propiedad es iniciarlos, detenerlos o habilitarlos y deshabilitarlos.
Como veis los usuarios no sysadmin no van a poder editar jobs que no sean suyos bajo ninguna circunstancia. A esto hay que sumarle que no se pueden poner grupos de usuarios o roles como propietarios de los trabajos.
Conclusión
El agente de SQL es un servicio que acompaña a SQL server y que nos va a facilitar en gran medida la programación de tareas y las labores de administración. Sin embargo su limitación en la gestión de permisos nos va a suponer un desafío al que todos los DBAs nos vamos a tener que enfrentar varias veces a lo largo de nuestra carrera. Por desgracia, a dia de hoy solo queda resignarnos y explicar al usuario lo que pasa.
Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!
