SQL Server Agent y Elastic Jobs

Cubre SQL Server Agent, Elastic Jobs, ARM/Bicep, Azure PowerShell y Azure Automation con sus límites de implementación y guía de selección.

El apartado de automatización del examen DP-300 pregunta "qué herramienta corresponde a cada modelo de implementación." La línea divisoria entre SQL Server Agent en Managed Instance y Elastic Jobs en Azure SQL Database es el eje central del examen. ARM/Bicep, Azure PowerShell, Azure CLI y Azure Automation ocupan roles distintos, y saber cuándo elegir cada uno es lo que separa las respuestas correctas de las trampas frecuentes.

 

SQL Server Agent — El Asistente Exclusivo de la Sede

Imagina un asistente personal que conoce a la perfección la agenda del director y resuelve cada tarea sin que se lo pidan, pero que nunca viaja a las sucursales. Eso es SQL Server Agent. Existe únicamente en Azure SQL Managed Instance y en SQL Server en Azure Virtual Machines. Azure SQL Database no lo soporta en absoluto, y este límite es el dato más evaluado sobre SQL Server Agent en el DP-300.

Los componentes esenciales son cuatro. Un es la unidad de trabajo. Los son las tareas individuales que se ejecutan en secuencia dentro de un Job, eligiendo cada uno un tipo: T-SQL, PowerShell, paquete SSIS o CmdExec. Un define cuándo se ejecuta el Job, y un es la persona que recibe las notificaciones.

Database Mail cierra el ciclo de notificaciones. Con un perfil SMTP configurado y vinculado a una Agent Alert, cualquier Job que falle envía un correo automáticamente al Operator. Toda la metadata — Jobs, Schedules, Alerts, Operators — se almacena en la base de datos de sistema . Las cuentas Proxy permiten ejecutar Steps específicos con credenciales de mínimo privilegio, aunque solo se aplican a subsistemas externos como CmdExec, PowerShell o SSIS — no a los Steps T-SQL.

 

Elastic Jobs — El Supervisor Regional

Gestionar una sola oficina es sencillo. Distribuir la misma hoja de verificación a cien sucursales y recopilar los resultados en paralelo es un reto completamente distinto. Elastic Jobs ejecuta scripts T-SQL en varios Azure SQL Databases, Elastic Pools y servidores de forma simultánea. Funciona exclusivamente dentro del ecosistema de Azure SQL Database — Managed Instance y SQL on VM no son destinos compatibles.

Tres componentes componen una configuración de Elastic Jobs. La es una Azure SQL Database dedicada que almacena las definiciones de los trabajos y el historial de ejecuciones. El define la colección de bases de datos — individuales, Elastic Pools o servidores completos — sobre las que debe ejecutarse un trabajo, con control preciso de inclusión y exclusión. El es el motor de ejecución administrado que lo orquesta todo.

Imagina un producto SaaS multitenant con decenas de bases de datos de cliente que necesitan recibir una nueva columna cada mes. Con SQL Server Agent necesitarías acceder a cada base de datos individualmente. Elastic Jobs registra todas las bases de datos de los clientes en un target group y dispara un único Job que se ejecuta en todas ellas al mismo tiempo. Los fallos quedan registrados por base de datos, de modo que solo es necesario reintentar las que fallaron.

 

Plantillas ARM y Bicep — Construir a partir de Planos

Cuando un equipo de construcción sigue los mismos planos cada vez, todos los edificios salen idénticos. Si improvisan, se van acumulando pequeñas diferencias. Las plantillas ARM y Bicep son los planos de la infraestructura Azure.

Una plantilla ARM declara los recursos Azure en formato JSON. Declaras "estos recursos deben existir con esta configuración" y Azure Resource Manager analiza las dependencias y los despliega en el orden correcto. La ventaja clave es la idempotencia: ejecutar la misma plantilla varias veces siempre produce el mismo estado final. Un fallo parcial seguido de un reintento solo crea los recursos que faltaban. Las plantillas se integran directamente en GitHub Actions o Azure Pipelines como pasos de despliegue.

Bicep es el lenguaje específico de dominio oficial para ARM. Expresa las mismas definiciones de recursos con aproximadamente un 40% menos de líneas y compila a ARM JSON en el momento del despliegue. El resultado funcional es idéntico. DACPAC empaqueta solo el esquema de la base de datos; BACPAC empaqueta esquema y datos. Ambos aparecen en escenarios de automatización de despliegue junto a ARM y Bicep.

 

Azure PowerShell y Azure CLI — Las Herramientas de Mando en Campo

Si las plantillas ARM declaran lo que debe existir, Azure PowerShell y Azure CLI emiten órdenes inmediatas e imperativas: "crea este recurso ahora mismo."

El módulo PowerShell ofrece cmdlets como , y . El pipeline de objetos y las construcciones condicionales de PowerShell lo hacen ideal para flujos de automatización complejos. El grupo de comandos de Azure CLI proporciona las mismas capacidades de forma multiplataforma: los mismos comandos funcionan en Windows, macOS y Linux, lo que los convierte en una opción natural para agentes CI/CD basados en Linux y runners de GitHub Actions.

Ambas herramientas admiten autenticación no interactiva mediante Service Principals o Managed Identities. Establecer un grupo de recursos predeterminado con elimina la necesidad de pasar en cada comando posterior; la configuración se guarda en y persiste entre sesiones de Cloud Shell.

 

Azure Automation — Orquestación en el Mundo Híbrido

Cuando todavía tienes servidores locales pero necesitas aplicar las mismas políticas de automatización en todas partes, Azure Automation tiende ese puente.

Los son scripts en PowerShell o Python que se programan en la nube o se activan mediante eventos. El rol extiende la ejecución a servidores locales o VMs en otras nubes, permitiendo que el mismo Runbook corra dentro de un datacenter protegido por firewall. A diferencia de SQL Server Agent o Elastic Jobs, que operan desde dentro de las instancias SQL, Azure Automation es un orquestador externo que gestiona recursos desde fuera. Las capacidades adicionales incluyen para el seguimiento de parches, para detectar desvíos de configuración y para el mantenimiento declarativo del estado de los servidores.

 

Guía de Decisión — Cuándo Usar Cada Herramienta

Una buena caja de herramientas tiene tanto martelo como destornillador, pero usar el martillo en un tornillo es un error. Conocer el límite de cada herramienta es la habilidad central tanto para el DP-300 como para la automatización real.

: solo Managed Instance y SQL on VM. Jobs T-SQL en instancia, mantenimiento nocturno, alertas Database Mail : solo Azure SQL Database. Ejecución T-SQL simultánea en múltiples DBs, Pools y Servidores : todos los recursos Azure. IaC declarativa, consistencia de entorno, integración GitHub Actions : todos los recursos Azure. Scripting imperativo, pasos de pipeline CI/CD : nube y entorno local. Programación de Runbooks, Hybrid Worker, DSC

 

Trampas Frecuentes — Dónde Suelen Fallar los Candidatos

"Desplegar un cambio de esquema en varios Azure SQL Databases simultáneamente" es una trampa clásica. SQL Server Agent no puede cruzar el límite de su propia instancia — la respuesta correcta es Elastic Jobs.

Lo contrario también es una trampa: "programar un Job de reconstrucción de índices nocturno en Managed Instance" emparejado con Elastic Jobs es incorrecto, porque Elastic Jobs solo soporta Azure SQL Database. Para despliegues repetidos del mismo entorno, ARM/Bicep es la opción adecuada. Para un cambio inmediato sobre un recurso existente, basta con un comando de Azure CLI. Combinar herramientas declarativas e imperativas es el patrón real de trabajo que el examen refleja en sus escenarios.

 

Resumen para el Examen

"Job de mantenimiento nocturno de índices en Managed Instance" -- SQL Server Agent "Instalar SQL Server Agent en Azure SQL Database" -- No es posible (Database no lo admite) "Ejecutar ALTER TABLE en 100 bases de datos de tenant a la vez" -- Elastic Jobs "Almacenamiento del historial de ejecución de Jobs" -- msdb (Agent) / Job database (Elastic Jobs) "IaC declarativa con garantía de idempotencia" -- Plantilla ARM / Bicep "En qué compila Bicep" -- ARM JSON "Automatizar la creación de un servidor SQL en GitHub Actions" -- Azure PowerShell o Azure CLI "Ejecutar un Runbook en un SQL Server local" -- Azure Automation Hybrid Runbook Worker "Perfil SMTP de Database Mail, sp_send_dbmail" -- Notificaciones de SQL Server Agent (solo MI/VM) "DACPAC vs BACPAC" -- DACPAC = solo esquema, BACPAC = esquema + datos

SQL Server Agent = exclusivo de Managed Instance y SQL on VM, Elastic Jobs = solo Azure SQL Database

Volver a la lista del blog