Creación, configuración y administración de trabajos elásticos (versión preliminar)

Artículo
04/26/2023

Se aplica a: Azure SQL Database

En este artículo, obtendrá información sobre cómo crear, configurar y administrar trabajos elásticos.

Si no ha usado los trabajos elásticos, aprenda más sobre los conceptos de automatización de los trabajos en Azure SQL Database.

Creación y configuración del agente

Cree o identifique una base de datos vacía S1 o superior. Esta base de datos se usará como la base de datos de trabajos durante la creación del agente de trabajos elásticos.
Cree un agente de trabajos elásticos en el portal o con PowerShell.

Creación, ejecución y administración de trabajos

Cree una credencial para la ejecución del trabajo en la base de datos de trabajos mediante PowerShell o T-SQL.
Defina el grupo de destino (las bases de datos en las que se quiere ejecutar el trabajo) mediante PowerShell o T-SQL.
Cree una credencial del agente de trabajos en cada base de datos en las que debe ejecutarse el trabajo (agregue el usuario (o el rol) a cada base de datos del grupo). Para obtener un ejemplo, consulte el tutorial de PowerShell.
Cree un trabajo mediante PowerShell o T-SQL.
Agregue pasos de trabajo mediante PowerShell o T-SQL.
Ejecute un trabajo mediante PowerShell o T-SQL.
Supervise el estado de ejecución del trabajo mediante el portal, PowerShell o T-SQL.

Credenciales para la ejecución de trabajos

Los trabajos usan credenciales de ámbito de base de datos para conectarse a las bases de datos que especifica el grupo de destino en la ejecució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.

La configuración de las credenciales adecuadas para ejecutar un trabajo puede ser un poco confusa, por lo que debe tener en cuenta los puntos siguientes:

Las credenciales de ámbito de base de datos se deben crear en la base de datos del trabajo.
Todas las bases de datos de destino deben tener un inicio de sesión con permisos suficientes para que el trabajo se complete correctamente ( 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 Trabajo.
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 siguiente imagen está diseñada para ayudar a comprender y configurar las credenciales del trabajo adecuadas. Recuerde que debe crear el usuario en cada base de datos (todas las bases de datos de usuario de destino) en las que se debe ejecutar el trabajo.

Credenciales de trabajos elásticos

Recomendaciones de seguridad

Algunas consideraciones sobre procedimientos recomendados para trabajar con trabajos elásticos:

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, capacidad y limitaciones del agente

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).

Evitar que los trabajos reduzcan el rendimiento de la base de datos de destino

Para asegurarse de que los recursos no están sobrecargados al ejecutar trabajos en las bases de datos de un grupo elástico de SQL, 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.

Restricciones conocidas

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

Incidencia	Descripción
El agente de Trabajos elásticos debe volver a crearse e iniciarse en la nueva región después de una conmutación por error o traslado a una nueva región de Azure.	El servicio Trabajos elásticos almacena todos sus metadatos de trabajo y agente de trabajo en la base de datos de trabajos. Cualquier conmutación por error o traslado de recursos de Azure a una nueva región de Azure también moverá la base de datos de trabajos, el agente de trabajo y los metadatos de los trabajos a la nueva región de Azure. Sin embargo, el agente de Trabajos elásticos es un recurso de solo proceso y debe volver a crearse e iniciarse explícitamente en la nueva región antes de que los trabajos empiecen a ejecutarse de nuevo en la nueva región. Una vez iniciado, el agente de Trabajos elásticos reanudará la ejecución de trabajos en la nueva región según la programación de trabajos definida previamente.
Límite de trabajos simultáneos.	Actualmente, la versión preliminar está limitada a 100 trabajos simultáneos.
Registros de auditoría excesivos de la base de datos de trabajos	El agente de trabajos elásticos funciona sondeando constantemente la base de datos de trabajos para comprobar la llegada de nuevos trabajos y otras operaciones CRUD. Si la auditoría está habilitada en el servidor que aloja una base de datos de trabajos, esta puede generar una gran cantidad de registros de auditoría. Para mitigarlo, puede filtrar estos registros de auditoría mediante el comando `Set-AzSqlServerAudit` con una expresión de predicado. Por ejemplo: `Set-AzSqlServerAudit -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -BlobStorageTargetState Enabled -StorageAccountResourceId "/subscriptions/7fe3301d-31d3-4668-af5e-211a890ba6e3/resourceGroups/resourcegroup01/providers/Microsoft.Storage/storageAccounts/mystorage" -PredicateExpression "database_principal_name <> '##MS_JobAccount##'"` Con este comando solo se filtrará el agente de trabajo a los registros de auditoría de la base de datos de trabajos, y no a los registros de auditoría de las bases de datos de destino.
No se admiten los puntos de conexión privados	Actualmente, los agentes de trabajos elásticos no se pueden conectar a bases de datos y grupos elásticos que restringen las conexiones a puntos de conexión privados.
Uso de una base de datos de Hiperescala como base de datos de trabajo	No se admite el uso de una base de datos de Hiperescala como base de datos de trabajo. Sin embargo, los trabajos elásticos pueden dirigirse a bases de datos de Hiperescala, de la misma manera que cualquier otra base de datos de Azure SQL Database.
Bases de datos sin servidor y pausado automático con trabajos elásticos.	Una base de datos sin servidor habilitada para pausa automática no se admite como base de datos de trabajo. Las bases de datos sin servidor objeto de un trabajo elástico admiten la pausa automática y se reanudarán mediante las conexiones del trabajo.

Procedimientos recomendados para crear trabajos

Tenga en cuenta los siguientes procedimientos recomendados al trabajar con trabajos de Base de datos elástica:

Scripts idempotentes

Los scripts de T-SQL de un trabajo 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.