Automatización de tareas de base de datos para la escalabilidad

  • 7 minutos

Al trabajar con la automatización desde SQL Server, es habitual usar el Agente SQL para programar trabajos con fines de automatización. Aunque las instancias de Azure SQL Managed Instance y SQL Server que se ejecutan en una máquina virtual de Azure siguen teniendo esa opción, no es así en el caso de Azure SQL Database, por lo que es posible que tenga que usar métodos de automatización alternativos para lograr resultados similares.

Azure Automation

Azure Automation permite la automatización de procesos, la administración de la configuración, la integración completa con las opciones de la plataforma Azure (como el control de acceso basado en rol y Microsoft Entra ID) y puede administrar recursos locales y de Azure.

Con Azure Automation, puede controlar fácilmente los recursos en máquinas virtuales locales y de Azure. Por ejemplo, puede usar runbooks híbridos para automatizar tareas como iniciar una máquina virtual, ejecutar una copia de seguridad de SQL Server y apagar la máquina virtual, lo que hace que sea rentable y eficaz.

Otro escenario común es usar Azure Automation para operaciones de mantenimiento periódicas, como purgar datos obsoletos o antiguos o volver a indexar una base de datos SQL.

Componentes

Azure Automation admite las actividades de administración de configuración y automatización. Si bien nos centraremos en los componentes de automatización, Azure Automation también puede usarse para administrar las configuraciones y las actualizaciones del servidor.

Componente Descripción
Runbook Los runbooks son la unidad de ejecución en Azure Automation. Los runbooks se definen dentro uno de estos tres tipos: un runbook gráfico basado en PowerShell, un script de PowerShell o un script de Python. Los runbooks de PowerShell se usan normalmente para administrar recursos de Azure SQL.
Módulo Azure Automation define un contexto de ejecución para el código de PowerShell o Python que se ejecuta en el runbook. Para ejecutar el código, debe importar los módulos auxiliares. Por ejemplo, si necesita ejecutar el cmdlet de PowerShell Get-AzSqlDatabase, deberá importar el módulo de PowerShell Az.SQL en la cuenta de Automation.
Credential: Las credenciales almacenan información confidencial que los runbooks o las configuraciones pueden usar en tiempo de ejecución.
Programación Las programaciones están vinculadas a runbooks y desencadenan un runbook en un momento determinado.

Para obtener más información sobre la CLI de Azure y los comandos de PowerShell disponibles para administrar recursos de Azure SQL Database y Azure SQL Managed Instance, consulte los vínculos siguientes: Módulo de PowerShell para Azure SQL y CLI de Azure para Azure SQL.

Trabajos elásticos

Uno de los motivos por los que muchos administradores de bases de datos están tan familiarizados con Azure Automation es que, inicialmente, a Azure SQL Database le faltaban funcionalidades para los trabajos programados.

Esta limitación significaba que los DBA tenían que encontrar soluciones alternativas para controlar estas tareas esenciales de forma eficaz. Azure Automation surgió como una herramienta valiosa en este escenario, ofreciendo los medios necesarios para crear y administrar trabajos programados, automatizar los procesos de migración de bases de datos y realizar tareas de mantenimiento rutinarias.

Architecture

La característica de trabajos elásticos permite ejecutar un conjunto de scripts de T-SQL en una colección de servidores o bases de datos como un trabajo único o mediante una programación definida. Los trabajos elásticos funcionan de forma similar a los trabajos de Agente SQL Server, con la salvedad de que están limitados a ejecutar T-SQL. Los trabajos funcionan en todos los niveles de la base de datos de Azure SQL.

Screenshot of the elastic job architecture diagram.

Para configurar trabajos elásticos, se necesita un agente de trabajo y una base de datos dedicada para administrar los trabajos. El nivel de servicio recomendado para la base de datos de trabajos es S1 o superior, y el nivel de servicio óptimo dependerá del número de trabajos que se ejecuten y de la frecuencia de esos trabajos.

Vamos a revisar los componentes de los trabajos elásticos:

  • Agente de trabajo elástico: el recurso de Azure para ejecutar y administrar los trabajos.
  • Base de datos de trabajos: una base de datos dedicada a administrar los trabajos.
  • Grupo de destino: una colección de servidores, grupos elásticos y bases de datos únicas en las que se ejecutará un trabajo.
  • Trabajo: uno o varios scripts de T-SQL que componen un paso de trabajo.

Si un servidor o grupo elástico es el destino, debe crearse una credencial en la base de datos maestra del servidor o grupo para que el agente de trabajo pueda enumerar las bases de datos dentro. Para una sola base de datos, se necesita una credencial de base de datos. Las credenciales deben tener los privilegios mínimos necesarios para realizar el paso de trabajo.

Screenshot of the elastic job agent creation page.

Puede crear un agente de trabajo elástico mediante Azure Portal. En la página Agente de trabajos elásticos, asegúrese de proporcionar un nombre para el agente y especifique una base de datos SQL para la base de datos de trabajos.

El siguiente script de PowerShell crea un trabajo elástico denominado MyFirstElasticJob, le agrega un paso de trabajo y ejecuta un comando SQL para crear una tabla si no existe en la base de datos.

Write-Output "Creating a new job..."
$jobName = "MyFirstElasticJob"
$job = $jobAgent | New-AzSqlElasticJob -Name $jobName -RunOnce

Write-Output "Creating job steps for $($jobName) job..."
$sqlText1 = "IF NOT EXISTS (SELECT * FROM sys.tables WHERE object_id = object_id('MyTable')) CREATE TABLE [dbo].[MyTable]([Id] [int] NOT NULL);"

$job | Add-AzSqlElasticJobStep -Name "Step1" -TargetGroupName $serverGroup.TargetGroupName -CredentialName $jobCred.CredentialName -CommandText $sqlText1

Por último, ejecute el trabajo elástico MyFirstElasticJob.

Write-Output "Start the job..."
$jobExecution = $job | Start-AzSqlElasticJob
$jobExecution

Escenarios de casos de uso

Los trabajos elásticos se pueden usar en los escenarios siguientes:

  • Automatización de las tareas de administración para que se ejecuten según una programación específica.
  • Implementación de cambios de esquema.
  • Movimientos de datos.
  • Recopilación y agregación de datos para informes u otros fines.
  • 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.
  • Procesamiento de datos en un gran número de bases de datos, por ejemplo, recopilación de telemetría. Los resultados se recopilan en una sola tabla de destino para su posterior análisis.

Migración de trabajos del Agente SQL a trabajos elásticos

Aunque es posible crear sus propios scripts para migrar los trabajos del Agente SQL a trabajos elásticos, hay una opción más cómoda disponible. Existe un script descargable que facilita la copia de los trabajos existentes del Agente SQL en trabajos elásticos.

El script es una herramienta que automatiza el proceso de conversión de estos trabajos, lo cual evita el tiempo y el esfuerzo de tener que volver a crearlos manualmente en el nuevo entorno.

El archivo es una carpeta comprimida que contiene el script y la documentación asociada. Para usarlo, debe descargar el archivo y seguir las instrucciones.

Después de escribir todos los parámetros indicados en las instrucciones, aparecerá la lista de trabajos. A continuación, el script creará cada trabajo individualmente en un estado deshabilitado, suponiendo que aún no existe. Después de la creación de un trabajo, se agregan los pasos con los mismos identificadores, texto de comando, reintentos e intervalo de reintento inicial en segundos. La base de datos vinculada al paso del trabajo será el grupo de destino. Si el grupo de destino no existe, se creará automáticamente. La copia no incluye programaciones, alertas y notificaciones.

Migración de trabajos del Agente SQL al Agente SQL en Azure

La migración de trabajos desde una instancia de SQL Server local a instancias de Azure SQL Managed Instance o SQL Server que se ejecutan en la máquina virtual sigue un proceso con el cual deberían estar familiarizados la mayoría de los DBA.

En nuestro escenario, supongamos que hemos migrado nuestra instancia de SQL Server local a Azure SQL Managed Instance. Es necesario migrar y ajustar varios trabajos del Agente SQL para que funcionen sin problemas en el entorno de Azure.

  • Evaluación de dependencias: identifique el trabajo del Agente SQL que desea migrar. Indique las dependencias, como servidores vinculados, credenciales y bases de datos, en las que se basa el trabajo

  • Script de trabajo del Agente SQL: cree el script de trabajo del Agente SQL en SQL Server como un script SQL. Para ello, haga clic con el botón derecho en el trabajo en SQL Server Management Studio (SSMS) y seleccione "Script de trabajo como" -> "Crear en" -> "Nueva ventana del Editor de consultas".

  • Modificación de dependencias de trabajo: revise el script SQL y modifique las dependencias de trabajo que puedan haber cambiado debido a la migración. Por ejemplo, si el trabajo hace referencia a un servidor vinculado o una ruta de acceso de archivo en el servidor local, actualícelo para que coincida con el nuevo entorno.

  • Creación de trabajos de Azure SQL MI: abra SSMS o Azure Data Studio y conéctese a Azure SQL Managed Instance. Cree un nuevo trabajo del Agente SQL con el script que generó anteriormente.

  • Creación de dependencias en Azure SQL MI: si el trabajo del Agente SQL se basa en servidores vinculados o credenciales, créelos en el entorno de Azure SQL MI. Asegúrese de que coinciden con la configuración de la instancia de SQL Server.

  • Programación del trabajo: configure la programación del trabajo en Azure SQL MI mediante el Agente SQL Server. Puede crear una nueva programación y vincularla al trabajo.

  • Pruebas: pruebe el trabajo del Agente SQL exhaustivamente en el entorno de Azure SQL MI para asegurarse de que se ejecuta según lo previsto. Compruebe si hay errores o problemas que puedan surgir debido a diferencias entre la instancia de SQL Server local y Azure SQL MI.

  • Supervisión y mantenimiento: supervise el rendimiento del trabajo y asegúrese de que sigue cumpliendo sus requisitos en el entorno de Azure SQL MI. Ajuste las configuraciones o programaciones según sea necesario.