Trabajos elásticos para Azure SQL Database

Se aplica a: Azure SQL Database

En este artículo, se revisan las funcionalidades y los detalles de los trabajos elásticos para Azure SQL Database.

• Para ver un tutorial sobre cómo configurar trabajos elásticos, consulte el tutorial sobre trabajos elásticos.
• Obtenga más información sobre los conceptos de automatización en las plataformas de base de datos de Azure.

Información general sobre trabajos elásticos

Puede crear y programar trabajos elásticos que se pueden ejecutar periódicamente en una o varias bases de datos de Azure SQL para ejecutar consultas de Transact-SQL (T-SQL) y realizar tareas de mantenimiento.

Puede definir la base de datos o los grupos de bases de datos de destino en que se ejecutará el trabajo, así como las programaciones para ejecutar un trabajo. Todas las fechas y horas de los trabajos elásticos se encuentran en la zona horaria UTC.

Un trabajo gestiona la tarea de iniciar sesión en la base de datos de destino. También define, mantiene y conserva los scripts de Transact-SQL que se van a ejecutar en un grupo de bases de datos.

Cada trabajo registra el estado de ejecución y también reintenta automáticamente las operaciones si se produce algún error.

Cuándo se usan trabajos elásticos

Son varios los escenarios en los que se puede usar la automatización de trabajos elásticos:

• Automatización de las tareas de administración y, luego, su programación para ejecutarlas todos los días laborables, después de horas, etc.
  • Implementar cambios de esquema, administración de credenciales.
  • Recopilación de datos de rendimiento o recopilación de telemetría de cuenta empresarial (cliente).
  • Actualización de datos de referencia (información común a todas las bases de datos).
  • Carga de datos desde Azure Blob Storage.
• Configuración de trabajos para su ejecución en una colección de bases de datos periódicamente como, por ejemplo, fuera de horas pico.
  • Recopile los resultados de consulta de un conjunto de bases de datos en una tabla central de forma continua.
  • Las consultas pueden ejecutarse continuamente y configurarse para que desencadenen la ejecución de otras tareas.
• Recopilación de datos para informes
  • Agregue datos de una colección de bases de datos a una tabla de destino única.
  • Ejecute consultas de procesamiento de datos de ejecución más larga en un conjunto grande de bases de datos; por ejemplo, la recopilación de telemetría de cliente. Los resultados se recopilan en una sola tabla de destino para su posterior análisis.
• Movimiento de datos
  • Para soluciones desarrolladas personalizadas, automatización empresarial u otra administración de tareas.
  • Procesamiento de ETL para extraer, procesar o insertar datos entre tablas de una base de datos.

Tenga en cuenta los trabajos elásticos cuando:

• Tenga una tarea que deba ejecutarse periódicamente según una programación, que tenga como destino una o varias bases de datos.
• Tenga una tarea que deba ejecutarse una vez, pero en varias bases de datos.
• Se deben ejecutar trabajos en cualquier combinación de bases de datos: una o varias bases de datos individuales, todas las bases de datos de un servidor o todas las bases de datos de un grupo elástico, con la flexibilidad adicional de poder incluir o excluir cualquier base de datos concreta. Los trabajos se pueden ejecutar en varios servidores, en varios grupos e incluso en bases de datos de distintas suscripciones. Los servidores y los grupos se enumeran dinámicamente en tiempo de ejecución, por lo que los trabajos se ejecutarán en todas las bases de datos que existan en el grupo de destino en el momento de la ejecución.
  • Se trata de una diferencia significativa del Agente SQL, que no puede enumerar dinámicamente las bases de datos de destino, especialmente en escenarios de cliente saaS en los que las bases de datos se agregan o eliminan dinámicamente.

Componentes de trabajos elásticos

Agente de trabajos elásticos

Un agente de trabajos elásticos es un recurso de Azure para crear, ejecutar y administrar trabajos. El agente de trabajos elásticos es un recurso de Azure que se crea en el portal (Crear y gestionar trabajos elásticos con PowerShell y API de REST también se admiten).

La creación de un agente de trabajos elásticos requiere una base de datos existente de Azure SQL Database. El agente configura esta base de datos de Azure SQL Database existente como la base de datos de trabajos.

Puede iniciar, deshabilitar o cancelar un trabajo a través de Azure Portal. Azure Portal también permite ver las definiciones de trabajos y el historial de ejecución.

Coste del agente de trabajos elásticos

La base de datos de trabajos se factura con la misma tarifa que cualquier base de datos de Azure SQL Database. Para el costo del agente de trabajo elástico, se basa en los precios fijos del nivel de servicio seleccionado para el agente de trabajo. Consulte la página de precios de Azure SQL Database.

Base de datos de trabajos elásticos

La base de datos de trabajos se utiliza para definir los trabajos y realizar el seguimiento del estado e historial de las ejecuciones de los trabajos. Los trabajos se ejecutan en bases de datos de destino. La base de datos de trabajos también se utiliza para almacenar metadatos del agente, registros, resultados, definiciones de trabajos y también contiene muchos procedimientos almacenados útiles y otros objetos de base de datos para crear, ejecutar y administrar trabajos mediante T-SQL.

Se recomienda una base de datos de Azure SQL Database (S1 o superior) para crear un agente de trabajos elásticos.

La base de datos de trabajos debe ser de Azure SQL Database, debe estar limpia y vacía y debe pertenecer al objetivo de servicio S1 o superior.

El objetivo de servicio recomendado de la base de datos de trabajos es S1 o superior, pero la opción óptima depende de las necesidades de rendimiento de los trabajos: el número de pasos de los trabajos, el número de destinos de los trabajos y la frecuencia con que se ejecutan los trabajos.

Si las operaciones realizadas en la base de datos de trabajos son más lentas de lo esperado, supervise el rendimiento de la base de datos y el uso de los recursos en la base de datos de trabajos durante los períodos de lentitud mediante Azure Portal o la vista de administración dinámica sys.dm_db_resource_stats. Si la utilización de un recurso, como la CPU, la E/S de datos o el registro de escritura, se aproxima al 100 % y se correlaciona con períodos de lentitud, considere la posibilidad de escalar incrementalmente la base de datos a objetivos de servicio más altos (ya sea en el modelo de compra basado en DTU o en el modelo de compra de núcleo virtual) hasta que el rendimiento de la base de datos mejore lo suficiente.

Trabajos elásticos y pasos de los trabajos

Un trabajo es una unidad de trabajo que se ejecuta según una programación o como un trabajo de una sola vez. Un trabajo consta de uno o varios pasos de trabajo.

Cada paso de trabajo especifica un script de T-SQL que se va a ejecutar, uno o varios grupos de destino en los que se va a ejecutar el script de T-SQL y las credenciales que necesita el agente de trabajos para conectarse a la base de datos de destino. Cada paso de trabajo tiene directivas de tiempo de espera y de reintento personalizables y, opcionalmente, puede especificar parámetros de salida.

Destinos de trabajos elásticos

Los trabajos elásticos proporcionan la posibilidad de ejecutar uno o varios scripts de T-SQL en paralelo, en un gran número de bases de datos, dentro de una programación o a petición. El destino puede ser cualquier nivel de Azure SQL Database.

Los trabajos programados se pueden ejecutar en cualquier combinación de bases de datos: una o varias bases de datos individuales, todas las bases de datos de un servidor o todas las bases de datos de un grupo elástico, con la flexibilidad adicional de poder incluir o excluir cualquier base de datos concreta. Los trabajos se pueden ejecutar en varios servidores, en varios grupos e incluso en bases de datos de distintas suscripciones. Los servidores y los grupos se enumeran dinámicamente en tiempo de ejecución, por lo que los trabajos se ejecutarán en todas las bases de datos que existan en el grupo de destino en el momento de la ejecución.

La siguiente imagen muestra a un agente de trabajos que ejecuta los trabajos en los diferentes tipos de grupos de destino:

Grupo de destino

Un grupo de destino define el conjunto de bases de datos en las que se ejecutará un paso de trabajo. Un grupo de destino puede contener cualquier número y combinación de los siguientes elementos:

• Servidor SQL Server lógico: si se especifica un servidor, todas las bases de datos que existen en él en el momento de la ejecución del trabajo forman parte del grupo. Se debe proporcionar la credencial de la base de datos master para que el grupo se pueda enumerar y actualizar antes de la ejecución del trabajo. Para más información sobre los servidores lógicos, consulte ¿Qué es un servidor lógico en Azure SQL Database y Azure Synapse?
• Grupo elástico: si se especifica un grupo elástico, todas las bases de datos que se encuentran en el grupo elástico en el momento de la ejecución del trabajo forman parte del grupo. Igual que para un servidor, se debe proporcionar la credencial de la base de datos master para que el grupo se pueda actualizar antes de la ejecución del trabajo.
• Base de datos individual: especifique una o más bases de datos individuales que van a formar parte del grupo.

Los grupos y bases de datos individuales se pueden especificar como incluidas o excluidas del grupo. Esto permite crear un grupo de destino con cualquier combinación de bases de datos. Por ejemplo, puede agregar un servidor a un grupo de destino, pero excluir bases de datos específicas de un grupo elástico (o excluir un grupo completo).

Un grupo de destino puede incluir bases de datos de varias suscripciones y de varias regiones. Las ejecuciones entre regiones tienen una latencia mayor que las ejecuciones en la misma región.

Los ejemplos siguientes muestran cómo se enumeran dinámicamente distintas definiciones de grupo de destino en el momento de la ejecución del trabajo para determinar en qué bases de datos se ejecutará el trabajo:

• El Ejemplo 1 muestra un grupo de destino que consta de una lista de bases de datos individuales. Cuando se ejecuta un paso de trabajo con este grupo de destino, la acción del paso de trabajo se ejecutará en cada una de esas bases de datos.
• El ejemplo 2 muestra un grupo de destino que contiene un servidor como destino. Cuando se ejecuta un paso de trabajo con este grupo de destino, el servidor se enumera de forma dinámica para determinar la lista de bases de datos que existen actualmente en el servidor. La acción del paso de trabajo se ejecutará en cada una de esas bases de datos.
• El Ejemplo 3 muestra un grupo de destino similar al del Ejemplo 2, pero se excluye específicamente una base de datos individual. La acción del paso de trabajo no se ejecutará en la base de datos excluida.
• El Ejemplo 4 muestra un grupo de destino que contiene un grupo elástico como destino. De forma similar al Ejemplo 2, el grupo se enumerará dinámicamente en tiempo de ejecución del trabajo para determinar la lista de bases de datos del grupo.

• Tanto el ejemplo 5 como el ejemplo 6 muestran escenarios avanzados en los que se pueden combinar servidores, grupos elásticos y bases de datos mediante reglas de inclusión y exclusión.

Autenticación

Elija un método para todos los destinos de un agente de trabajos elásticos. Por ejemplo, para un único agente de trabajos elásticos, no puede configurar un servidor de destino para usar credenciales de ámbito de base de datos y otra para usar la autenticación de Microsoft Entra ID.

El agente de trabajos elásticos puede conectarse a los servidores o bases de datos especificados por el grupo de destino mediante dos opciones de autenticación:

• Use la autenticación de Microsoft Entra (anteriormente Azure Active Directory) con una identidad administrada asignada por el usuario (UMI).
• Utilice credenciales de ámbito de base de datos.

Autenticación a través de la identidad administrada asignada por el usuario (UMI)

La autenticación de Microsoft Entra (anteriormente Azure Active Directory) a través de la identidad administrada asignada por el usuario (UMI) es la opción recomendada para conectar trabajos elásticos a Azure SQL Database. Con la compatibilidad con Microsoft Entra ID, el agente de trabajo podrá conectarse a bases de datos de destino (bases de datos, servidores, grupos elásticos) y bases de datos de salida mediante la UMI.

Opcionalmente, la autenticación de Microsoft Entra ID también se puede habilitar en el servidor lógico que contiene la base de datos de trabajos elásticos, para acceder a esa base de datos o consultarla a través de conexiones de Microsoft Entra ID. Sin embargo, el propio agente de trabajo usa la autenticación interna basada en certificados para conectarse a su base de datos de trabajos.

Puede crear una UMI o usar una UMI existente y asignar la misma UMI a varios agentes de trabajo. Solo se admite una UMI por agente de trabajo. Una vez que se asigna una UMI a un agente de trabajo, ese agente de trabajos solo usará esta identidad para conectarse y ejecutar trabajos de T-SQL en las bases de datos de destino. La autenticación de SQL no se usará en el servidor o las bases de datos de destino de ese agente de trabajo.

El nombre de la UMI debe comenzar con una letra o un número y con una longitud entre 3 y 128. Puede contener los caracteres - y _.

Para más información sobre la UMI en Azure SQL Database, consulte Identidades administradas para Azure SQL, incluidos los pasos necesarios y las ventajas de usar una UMI como identidad del servidor lógico de Azure SQL Database. Para más información, consulte Uso de la autenticación de Microsoft Entra.

La identidad administrada asignada por el sistema (SMI) no es compatible.

Autenticación mediante credenciales de ámbito de base de datos

Aunque la autenticación de Microsoft Entra (anteriormente Azure Active Directory) es la opción recomendada, los trabajos se pueden configurar para usar credenciales de ámbito de base de datos para conectarse a las bases de datos especificadas por el grupo de destino tras la ejecución. Antes de octubre de 2023, las credenciales de ámbito de base de datos eran la única opción de autenticación.

Si un grupo de destino contiene servidores o grupos, estas credenciales de ámbito de base de datos se utilizan para conectarse a la base de datos master para enumerar las bases de datos disponibles.

• Las credenciales de ámbito de base de datos se deben crear en la base de datos de trabajos.
• Todas las bases de datos de destino deben tener un inicio de sesión con permisos suficientes para que el trabajo se complete correctamente (jobuser en el siguiente diagrama).
• Las credenciales creadas en las bases de datos de destino (LOGIN y PASSWORD para masteruser y jobuser en el diagrama siguiente) deben coincidir con IDENTITY y SECRET en las credenciales creadas en la base de datos de trabajos.
• Las credenciales se pueden reutilizar en los trabajos y las contraseñas de las credenciales se cifran y protegen para los usuarios que tienen acceso de solo lectura a los objetos del trabajo.

La imagen siguiente está diseñada para ayudar a comprender la configuración de las credenciales de trabajo adecuadas y cómo se conecta el agente de trabajos elásticos mediante credenciales de base de datos como autenticación para inicios de sesión o usuarios en servidores o bases de datos de destino.

Puntos de conexión privados de trabajos elásticos

El agente de trabajos elásticos admite puntos de conexión privados de trabajos elásticos. La creación de un punto de conexión privado de trabajos elásticos establece un vínculo privado entre el trabajo elástico y el servidor de destino. La característica de puntos de conexión privados de trabajos elásticos es diferente de Azure Private Link.

La característica de puntos de conexión privados de trabajos elásticos admite conexiones privadas a servidores de destino o salida, de modo que el agente de trabajo todavía puede llegar a ellos incluso cuando la opción "Denegar acceso público" está habilitada. El uso de puntos de conexión privados también es una posible solución si desea deshabilitar la opción "Permitir que los servicios y recursos de Azure accedan a ese servidor".

Los puntos de conexión privados de trabajos elásticos admiten todas las opciones de autenticación del agente de trabajos elásticos.

La característica de punto de conexión privado del trabajo elástico permite elegir un punto de conexión privado administrado por el servicio para establecer una conexión segura entre el agente de trabajo y sus servidores de destino o salida. Un punto de conexión privado administrado por el servicio es una dirección IP privada en una red virtual y una subred específicas. Al elegir usar puntos de conexión privados en uno de los servidores de destino o salida del agente de trabajo, Microsoft crea un punto de conexión privado administrado por el servicio. A continuación, el agente de trabajo usa este punto de conexión privado exclusivamente para conectarse y ejecutar trabajos, o para escribir la salida del trabajo en esas bases de datos de destino o salida.

Los puntos de conexión privados de trabajos elásticos se pueden crear y permitir a través de Azure Portal. Los servidores de destino conectados a través del vínculo privado pueden estar en cualquier lugar de Azure, incluso en distintas zonas geográficas y suscripciones. Debe crear un punto de conexión privado para cada servidor de destino deseado y el servidor de salida del trabajo para habilitar esta comunicación.

Para ver un tutorial para configurar un nuevo punto de conexión privado administrado por el servicio para trabajos elásticos, consulte Configuración del punto de conexión privado de trabajos elásticos de Azure SQL.

Requisitos para puntos de conexión privados de trabajos elásticos

• Para usar un punto de conexión privado de trabajos elásticos, el agente de trabajo y las bases de datos y los servidores de destino deben estar hospedados en Azure (en la misma región o en regiones diferentes) y en el mismo tipo de nube (por ejemplo, en la nube pública o en la nube gubernamental).
• El proveedor de recursos Microsoft.Network debe estar registrado para las suscripciones de hospedaje del agente de trabajo y los servidores de destino o salida.
• Los puntos de conexión privados de trabajos elásticos se crean por servidor de destino o salida. Deben aprobarse para que el agente de trabajos elásticos pueda usarlos. Esto se puede hacer a través del panel Redes de ese servidor lógico o su cliente preferido. Después, el agente de trabajos elásticos podrá acceder a las bases de datos de ese servidor mediante una conexión privada.
• La conexión del agente de trabajos elásticos a la base de datos de trabajos no usará el punto de conexión privado. El propio agente de trabajo usa la autenticación interna basada en certificados para conectarse a su base de datos de trabajos. Si agrega la base de datos de trabajos como miembro del grupo de destino, saltará una advertencia. Después, se comporta como un destino normal que tendría que configurar con el punto de conexión privado según sea necesario.

Permisos de la base de datos de trabajos

Durante la creación del agente de trabajos, se crean un esquema, tablas y un rol llamado jobs_reader en la base de datos de trabajos. El rol se crea con los permisos siguientes y está diseñado para proporcionar a los administradores un mayor control de acceso para la supervisión de trabajos. Los administradores pueden proporcionar a los usuarios la capacidad de supervisar la ejecución del trabajo agregándolos al rol de jobs_reader en la base de datos de trabajos.

Supervisión de trabajos elásticos

El agente de trabajos elásticos está integrado con las Alertas de Azure para las notificaciones de estado del trabajo, lo que simplifica la solución para supervisar el estado y el historial de ejecución del trabajo.

Azure Portal también tiene nuevas características adicionales para admitir la supervisión de trabajos y trabajos elásticos. En la página Información general del agente de trabajos elásticos, se muestran las ejecuciones de trabajos más recientes, como en la captura de pantalla siguiente.

Puede crear Reglas de alertas de Azure Monitor con Azure Portal, la CLI de Azure, PowerShell y la API de REST. La métrica Trabajos elásticos erróneos es un buen punto inicial para supervisar y recibir alertas sobre la ejecución del trabajo elástico. Además, puede optar por recibir alertas a través de una acción configurable, como SMS o correo electrónico, mediante la instalación de Alertas de Azure. Para más información, consulte Crear alertas de Azure SQL Database en Azure Portal.

Para obtener un ejemplo, consulte Creación, configuración y administración de trabajos elásticos.

Salida del trabajo

El resultado de los pasos de un trabajo en cada base de datos de destino se registra en detalle y se puede capturar la salida del script en una tabla especificada. Puede especificar una base de datos para guardar los datos devueltos de un trabajo.

Historial de trabajos

Vea el historial de ejecución de trabajos elásticos en la base de datos de trabajos mediante una consulta en la tabla jobs.job_executions. Un trabajo de limpieza del sistema purga el historial de ejecución anterior a 45 días. Para eliminar un historial de menos de 45 días de antigüedad de forma manual, ejecute el procedimiento almacenado sp_purge_jobhistory de la base de datos de trabajos.

Estado del trabajo

Puede supervisar las ejecuciones de trabajos elásticos en la base de datos de trabajos consultando la tabla jobs.job_executions.

procedimientos recomendados

Tenga en cuenta los siguientes procedimientos recomendados al trabajar con bases de datos de trabajos elásticos.

Recomendaciones de seguridad

• Limitar el uso de las API a las personas de confianza.
• Las credenciales deben tener los privilegios mínimos necesarios para realizar el paso de trabajo. Para más información, consulte Autorización y permisos.
• Cuando se utiliza un servidor o un miembro del grupo de destino, se recomienda crear una credencial independiente con derechos en la base de datos master para ver y enumerar las bases de datos, que se utiliza para expandir las listas de bases de datos de los servidores o grupos antes de la ejecución del trabajo.

Rendimiento de los trabajos elásticos

Los trabajos elásticos utilizan recursos de proceso mínimos mientras se espera hasta que los trabajos de larga ejecución finalicen.

Dependiendo del tamaño del grupo de destino de las bases de datos y el tiempo de ejecución deseado para un trabajo (número de trabajadores simultáneos), el agente requiere distintas cantidades de proceso y rendimiento de la base de datos de trabajos (cuantos más destinos y número de trabajos, mayor será la cantidad de proceso necesaria).

Niveles de capacidades concurrentes

A partir de octubre de 2023, el agente de trabajo elástico tiene varios niveles de rendimiento para permitir el aumento de la capacidad.

Los incrementos de capacidad indican el número total de bases de datos de destino simultáneas a las que el agente de trabajo puede conectarse e iniciar un trabajo. Para obtener más conexiones de destino simultáneas para la ejecución del trabajo, actualice el nivel de un agente de trabajo del nivel JA100 predeterminado, que tiene un límite de 100 conexiones de destino simultáneas.

La mayoría de los entornos requieren menos de 100 trabajos simultáneos en cualquier momento, por lo que JA100 es el valor predeterminado.

Si se supera el nivel de capacidad de simultaneidad del agente de trabajo con destinos de trabajo, se crearán retrasos de puesta en cola para algunas bases de datos o servidores de destino. Por ejemplo, si inicias un trabajo con 110 destinos en el nivel JA100, 10 destinos esperarán a empezar hasta que finalicen otros.

El objetivo del nivel o servicio de un agente de trabajo elástico se puede modificar a través de Azure Portal, PowerShell o la API de REST de agentes de trabajo. Para obtener un ejemplo, consulte Escalado del agente de trabajo.

Limitar el impacto del trabajo en grupos elásticos

Para asegurarse de que los recursos no están sobrecargados al ejecutar trabajos en las bases de datos de un grupo elástico de Azure SQL Database, los trabajos se pueden configurar para limitar el número de bases de datos en las que puede ejecutarse un trabajo al mismo tiempo.

Establezca el número de bases de datos simultáneas que ejecuta un trabajo estableciendo el parámetro @max_parallelism del procedimiento almacenado sp_add_jobstep en T-SQL.

Scripts idempotentes

Los scripts de T-SQL de un trabajo elástico deben ser idempotentes. Idempotente significa que si el script se ejecuta correctamente y se vuelve a ejecutar, produce el mismo resultado. Un script puede producir errores debido a problemas de red transitorios. En ese caso, el trabajo volverá a intentar ejecutar automáticamente el script un número de veces predefinido antes de desistir. Un script idempotente produce el mismo resultado aunque se ejecute correctamente dos veces (o más).

Una táctica sencilla es probar la existencia de un objeto antes de crearlo. A continuación se muestra un ejemplo hipotético:

IF NOT EXISTS (SELECT * FROM sys.objects WHERE [name] = N'some_object')
    print 'Object does not exist'
    -- Create the object
ELSE
    print 'Object exists'
    -- If it exists, drop the object before recreating it.

De forma similar, un script debe ser capaz de comprobar lógicamente y contrarrestar las condiciones que encuentre para ejecutarse correctamente.

Limitaciones

Estas son las limitaciones actuales del servicio de trabajos elásticos. Estamos trabajando activamente para eliminar tantas limitaciones como sea posible.

Contenido relacionado

• Creación, configuración y administración de trabajos elásticos
• Automatización de tareas de administración en Azure SQL
• Creación y administración de trabajos elásticos mediante PowerShell
• Creación y administración de trabajos elásticos mediante T-SQL

Paso siguiente