En este artículo se proporciona información general sobre el Agente SQL Server, que es un servicio de Microsoft Windows que ejecuta tareas administrativas programadas (denominadas trabajos ) en SQL Server e Instancia administrada de Azure SQL.
El Agente SQL Server usa SQL Server para almacenar información del trabajo. Los trabajos contienen uno o varios pasos de trabajo. Cada paso contiene su propia tarea, por ejemplo, la copia de seguridad de una base de datos.
El Agente SQL Server puede ejecutar un trabajo según una programación, en respuesta a un evento específico o a petición. Por ejemplo, si desea realizar una copia de seguridad de todos los servidores de la empresa cada día laborable después del horario laboral, puede automatizar esta tarea. Programe la copia de seguridad para que se ejecute después de las 22:00 de lunes a viernes. Si la copia de seguridad encuentra un problema, el Agente SQL Server puede registrar el evento y notificarle.
Nota
De forma predeterminada, el servicio agente SQL Server está deshabilitado cuando SQL Server está instalado, a menos que el usuario elija explícitamente iniciar automáticamente el servicio.
Componentes del Agente SQL Server
El Agente SQL Server usa los siguientes componentes para definir las tareas que se van a realizar, cuándo realizar las tareas y cómo notificar el éxito o error de las tareas.
Use el Administrador de configuración de SQL Server para administrar el servicio Agente de SQL Server y use SQL Server Management Studio (SSMS) para administrar fácilmente las propiedades, los trabajos, las alertas, los operadores y los proxies de SQL Server en una interfaz gráfica de usuario.
Trabajos
Un trabajo es una serie especificada de acciones que realiza el Agente SQL Server. Use trabajos para definir una tarea administrativa que se pueda ejecutar una o varias veces y supervisar si se ha realizado correctamente o no. Un trabajo se puede ejecutar en un servidor local o en varios servidores remotos.
Importante
Los trabajos del Agente SQL Server que se ejecutan en el momento de un evento de conmutación por error en una instancia de clúster de conmutación por error de SQL Server no se reanudan después de la conmutación por error a otro nodo de clúster de conmutación por error. Los trabajos del Agente SQL Server que se ejecutan en el momento en que se pausa un nodo de Hyper-V no se reanudan si la pausa provoca una conmutación por error a otro nodo. Los trabajos que comienzan pero no se completan debido a un evento de conmutación por error se registran como iniciados, pero no muestran entradas de registro adicionales para la finalización o el error. Los trabajos del Agente SQL Server en estos escenarios parecen no haber finalizado nunca.
Puede ejecutar trabajos de varias maneras:
De acuerdo con uno o varios horarios.
En respuesta a una o varias alertas.
Ejecutando el procedimiento almacenado sp_start_job.
Cada acción de un trabajo es un paso de trabajo . Por ejemplo, un paso de trabajo puede constar de ejecutar una instrucción Transact-SQL, ejecutar un paquete SSIS o emitir un comando a un servidor de Analysis Services. Los pasos de trabajo se administran como parte de un trabajo.
Cada paso de trabajo se ejecuta en un contexto de seguridad específico. Para los pasos de trabajo que usan Transact-SQL, use la instrucción EXECUTE AS para establecer el contexto de seguridad para el paso de trabajo. Para otros tipos de pasos de trabajo, use una cuenta de proxy para establecer el contexto de seguridad del paso de trabajo.
Use el procedimiento almacenado del sistema sp_help_job para obtener información sobre un trabajo específico. Utilice la tabla del sistema dbo.sysjobs para ver información sobre las tareas. Por ejemplo, use la siguiente instrucción Transact-SQL (T-SQL) para ver información sobre todos los trabajos de un servidor:
SQL
USE MSDB
GOSELECT job_id, [name] FROM dbo.sysjobs;
Horarios
Un programa especifica cuándo se ejecuta un trabajo. Se puede ejecutar más de un trabajo en la misma programación y se puede aplicar más de una programación al mismo trabajo. Una programación puede definir las condiciones siguientes para el momento en que se ejecuta un trabajo:
Siempre que se inicie el Agente SQL Server.
Siempre que el uso de cpu del equipo esté en un nivel que haya definido como inactivo.
Un alerta es una respuesta automática a un evento específico. Por ejemplo, un evento puede ser un trabajo que inicia o recursos del sistema que alcanzan un umbral específico. Defina las condiciones en las que se produce una alerta.
Una alerta puede responder a una de las condiciones siguientes:
Eventos de SQL Server
Condiciones de rendimiento de SQL Server
Eventos de Instrumentación de Administración de Microsoft Windows (WMI) en el equipo donde se ejecuta el Agente de SQL Server
Una alerta puede realizar las siguientes acciones:
Un operador define la información de contacto de un individuo responsable del mantenimiento de una o varias instancias de SQL Server. En algunas empresas, las responsabilidades del operador se asignan a una persona. En empresas con varios servidores, muchas personas pueden compartir responsabilidades de operador. Un operador no contiene información de seguridad y no define un principal de seguridad.
SQL Server puede notificar a los operadores de alertas a través de...
Correo electrónico
Notificación (por correo electrónico)
de envío neto
Nota
Para enviar notificaciones mediante net send, el servicio Windows Messenger debe iniciarse en el equipo donde reside el Agente SQL Server.
Importante
Las opciones Pager y net send se quitarán del Agente de SQL Server en una versión futura de SQL Server. Evite usar estas características en el nuevo trabajo de desarrollo y planee modificar las aplicaciones que actualmente usan estas características.
Para enviar notificaciones a los operadores mediante correo electrónico o buscapersonas, debe configurar el Agente SQL Server para que use correo electrónico de base de datos. Para obtener más información, consulte Correo de base de datos.
Puede definir un operador como alias para un grupo de individuos. De este modo, no se verifican todos los miembros de ese alias al mismo tiempo. Para obtener más información, consulte Operadores .
Seguridad para la administración del Agente SQL Server
El Agente SQL Server utiliza los roles fijos de base de datos SQLAgentUserRole, SQLAgentReaderRoley SQLAgentOperatorRole en la base de datos msdb para controlar el acceso al Agente SQL Server de los usuarios que no son miembros del rol fijo de servidor sysadmin. Además de estos roles fijos de base de datos, los subsistemas y los servidores proxy ayudan a los administradores de bases de datos a asegurarse de que cada paso de trabajo se ejecuta con los permisos mínimos necesarios para realizar su tarea.
Roles
Los miembros de los roles fijos de base de datos SQLAgentUserRole, SQLAgentReaderRoley SQLAgentOperatorRole en msdb, y los miembros del rol fijo de servidor sysadmin tienen acceso al Agente SQL Server. Un usuario que no pertenece a ninguno de estos roles no puede usar el Agente SQL Server. Para obtener más información sobre los roles usados por el Agente SQL Server, vea Implementar seguridad del Agente SQL Server.
Subsistemas
Un subsistema es un objeto predefinido que representa la funcionalidad que está disponible para un paso de trabajo. Cada proxy tiene acceso a uno o varios subsistemas. Los subsistemas proporcionan seguridad porque delimitan el acceso a la funcionalidad que está disponible para un proxy. Cada paso de trabajo se ejecuta en el contexto de un proxy, excepto Transact-SQL paso de trabajo. Pasos del trabajo Transact-SQL, use el comando EXECUTE AS para establecer el contexto de seguridad al propietario del trabajo.
SQL Server define los subsistemas enumerados en la tabla siguiente:
Nombre del subsistema
Descripción
Microsoft ActiveX Script
Ejecutar un paso de trabajo de scripting de ActiveX.
#Advertencia El subsistema de scripting ActiveX se eliminará del Agente SQL Server en una versión futura de Microsoft SQL Server. Evite usar esta característica en el nuevo trabajo de desarrollo y planee modificar las aplicaciones que actualmente usan esta característica.
Sistema operativo (CmdExec)
Ejecute un programa ejecutable.
PowerShell
Ejecute un paso de trabajo de un script de PowerShell.
Distribuidor de replicación
Ejecute un paso de trabajo que active el Agente de distribución de replicación.
Mezcla de replicación
Ejecute un paso de trabajo que active el Agente de mezcla de replicación.
Lector de colas de replicación
Ejecute un paso de trabajo que active el Agente de lectura de cola de replicación.
Instantánea de replicación
Ejecute un paso de trabajo que active el Agente de instantáneas de replicación.
Lector del registro de transacciones de replicación
Ejecute un paso de trabajo que active el Agente lector de registros de replicación.
Comando de Servicios de Análisis
Ejecute un comando de Analysis Services.
Consulta de Servicios de Análisis
Ejecute una consulta de Analysis Services.
Ejecución de paquetes SSIS
Ejecute un paquete SSIS.
Nota
Dado que los pasos de trabajo de Transact-SQL no usan servidores proxy, no hay subsistema del Agente SQL Server para los pasos de trabajo de Transact-SQL.
El Agente SQL Server aplica restricciones de subsistema incluso cuando la entidad de seguridad del proxy normalmente tendría permiso para ejecutar la tarea en el paso de trabajo. Por ejemplo, un proxy para un usuario que sea miembro del rol fijo de servidor sysadmin no puede ejecutar un paso de trabajo de SSIS a menos que el proxy tenga acceso al subsistema SSIS, aunque el usuario pueda ejecutar paquetes SSIS.
Proxies
El Agente SQL Server usa servidores proxy para administrar contextos de seguridad. Un proxy se puede usar en más de un paso de trabajo. Los miembros del sysadmin rol fijo de servidor pueden crear servidores proxy.
Cada proxy corresponde a una credencial de seguridad. Cada proxy se puede asociar a un conjunto de subsistemas y a un conjunto de inicios de sesión. El proxy solo se puede usar para los pasos de trabajo que usan un subsistema asociado al proxy. Para crear un paso de trabajo que use un proxy específico, el propietario del trabajo debe usar un inicio de sesión asociado a ese proxy o ser miembro de un rol con acceso sin restricciones a los proxies. Miembros del rol fijo de servidor sysadmin tienen acceso sin restricciones a los proxies. Los miembros de SQLAgentUserRole, SQLAgentReaderRoleo SQLAgentOperatorRole solo pueden usar servidores proxy a los que se les ha concedido acceso específico. A cada usuario que sea miembro de cualquiera de estos roles fijos de base de datos del Agente SQL Server se le debe conceder acceso a servidores proxy específicos para que el usuario pueda crear pasos de trabajo que usen esos servidores proxy.
Automatización de la administración
Siga estos pasos para configurar el Agente SQL Server para automatizar la administración de SQL Server:
Establezca qué tareas administrativas o eventos de servidor se producen periódicamente y si estas tareas o eventos se pueden administrar mediante programación. Una tarea es una buena candidata para la automatización si implica una secuencia predecible de pasos y se produce en un momento específico o en respuesta a un evento específico.
Defina un conjunto de trabajos, programaciones, alertas y operadores mediante SQL Server Management Studio, scripts de Transact-SQL o Objetos de administración de SQL Server (SMO). Para obtener más información, vea Crear empleos.
Ejecute los trabajos del Agente SQL Server que ha definido.
Nota
Para la instancia predeterminada de SQL Server, el servicio SQL Server se denomina SQLSERVERAGENT. En el caso de las instancias con nombre, el servicio agente SQL Server se denomina SQLAgent$nombreDeInstancia.
Si ejecuta varias instancias de SQL Server, puede usar la administración multiservidor para automatizar tareas comunes en todas las instancias. Para obtener más información, consulte Administración Automatizada a Través de una Empresa.
Use las siguientes tareas para empezar a trabajar con el Agente SQL Server:
Describe el Asistente para planes de mantenimiento, que es una utilidad que se usa para crear trabajos, alertas y operadores para automatizar la administración de una instancia de SQL Server.
A partir de SQL Server 2019, puede deshabilitar SQLPS. En la primera línea de un paso de trabajo del tipo PowerShell, puede agregar #NOSQLPS, que impide que el Agente SQL cargue automáticamente el módulo SQLPS. Ahora el trabajo del Agente SQL ejecuta la versión de PowerShell instalada en el equipo y, a continuación, puede usar cualquier otro módulo de PowerShell que desee.
Para usar el módulo SqlServer en el paso del trabajo del Agente SQL, puedes colocar este código en las dos primeras líneas de tu script.
Administre una infraestructura de base de datos de SQL Server para bases de datos relacionales locales e híbridas en la nube mediante las ofertas de bases de datos relacionales PaaS de Microsoft.