Automatiser les tâches de base de données pour la scalabilité

7 minutes

Lorsque vous utilisez l’automatisation à partir de SQL Server, il est courant d’utiliser SQL Agent pour planifier des travaux à des fins d’automatisation. Bien qu’Azure SQL Managed Instance et SQL Server s’exécutant sur une machine virtuelle Azure disposent toujours de cette option, ce n’est pas le cas d’Azure SQL Database. Vous devrez peut-être adopter d’autres méthodes d’automatisation pour obtenir des résultats similaires.

Azure Automation

Azure Automation permet l’automatisation des processus, la gestion de la configuration, l’intégration complète avec les options de la plateforme Azure (telles que le contrôle d’accès en fonction du rôle et Microsoft Entra ID), et il peut gérer des ressources Azure et locales.

Avec Azure Automation, vous pouvez facilement contrôler les ressources dans les machines virtuelles Azure et locales. Par exemple, vous pouvez utiliser des runbooks hybrides pour automatiser des tâches telles que le démarrage d’une machine virtuelle, l’exécution d’une sauvegarde SQL Server et l’arrêt de la machine virtuelle, ce qui en fait un outil rentable et efficace.

Un autre scénario courant consiste à utiliser Azure Automation pour les opérations de maintenance périodiques, notamment la purge de données obsolètes ou anciennes et la réindexation d’une base de données SQL.

Composants

Azure Automation prend en charge les activités d’automatisation et de gestion de la configuration. Nous allons nous concentrer sur les composants d’automatisation, mais vous pouvez également utiliser Azure Automation pour gérer les configurations et les mises à jour de serveur.

Composant	Description
Runbook	Les runbooks sont l’unité d’exécution dans Azure Automation. Les runbooks sont définis comme l’un des trois types suivants : un runbook graphique basé sur PowerShell, un script PowerShell ou un script Python. Les runbooks PowerShell sont généralement utilisés pour gérer les ressources Azure SQL.
Module	Azure Automation définit un contexte d’exécution pour le code PowerShell ou Python exécuté dans le runbook. Pour exécuter votre code, vous devez importer les modules de prise en charge. Par exemple, si vous avez besoin d’exécuter l’applet de commande PowerShell `Get-AzSqlDatabase`, vous devez importer le module PowerShell `Az.SQL` dans votre compte Automation.
Informations d'identification	Les informations d’identification permettent de stocker de manière sécurisée des informations sensibles que les runbooks et les configurations peuvent utiliser au moment de l’exécution.
Planification	Les planifications sont liées à des runbooks, et déclenchent un runbook à un moment donné.

Pour en savoir plus sur les commandes PowerShell et Azure CLI disponibles pour la gestion des ressources Azure SQL Database et Azure SQL Managed Instance, consultez les liens suivants : Module PowerShell pour Azure SQL et Azure CLI pour Azure SQL.

Tâches élastiques

L’une des raisons pour lesquelles un grand nombre d’administrateurs de bases de données se sont familiarisés avec Azure Automation est le fait qu’il manquait initialement des fonctionnalités pour les travaux planifiés dans Azure SQL Database.

Cette limitation signifiait que les administrateurs de base de données devaient trouver d’autres solutions pour gérer efficacement ces tâches essentielles. Azure Automation est devenu un outil précieux dans ce scénario, car il permet de créer et de gérer des travaux planifiés, d’automatiser les processus de migration de base de données et d’effectuer des tâches de maintenance de routine.

Architecture

La fonctionnalité de travaux élastiques vous permet d’exécuter un ensemble de scripts T-SQL sur une collection de serveurs ou de bases de données en tant que travail ponctuel, ou à l’aide d’une planification définie. Les travaux élastiques fonctionnent d’une manière analogue aux travaux SQL Server Agent, mais ils sont limités à l’exécution de T-SQL. Les travaux fonctionnent dans tous les niveaux d’Azure SQL Database.

Screenshot of the elastic job architecture diagram.

Pour configurer des travaux élastiques, vous avez besoin d’un agent de travail et d’une base de données dédiés à la gestion de vos travaux. Le niveau de service recommandé de la base de travaux est S1 ou supérieur. Le niveau de service optimal dépend du nombre et de la fréquence des travaux que vous exécutez.

Examinons les composants des travaux élastiques :

Agent de travail élastique : votre ressource Azure qui permet d’exécuter et de gérer des travaux.
Base de données de travaux : base de données dédiée à la gestion de vos travaux.
Groupe cible : collection de serveurs, de pools élastiques et de bases de données uniques dans lesquelles un travail est exécuté.
Travail : un ou plusieurs scripts T-SQL qui composent une étape de travail.

Si la cible est un serveur ou un pool élastique, des informations d’identification dans la base de données MASTER du serveur ou du pool doivent être créées afin que l’agent de travail puisse énumérer les bases de données qui s’y trouvent. Pour une base de données unique, les informations d’identification de base de données sont les seules informations nécessaires. Les informations d’identification doivent avoir les privilèges minimaux nécessaires pour effectuer l’étape de travail.

Screenshot of the elastic job agent creation page.

Vous pouvez créer un agent de travail élastique via le portail Azure. Dans la page Agent de travail élastique, assurez-vous de fournir un nom pour votre agent et de spécifier une base de données SQL pour votre base de données de travaux.

Le script PowerShell suivant crée un travail élastique nommé MyFirstElasticJob, y ajoute une étape de travail, et exécute une commande SQL pour créer une table si elle n’existe pas dans la base de données.

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

Pour finir, exécutez le travail élastique MyFirstElasticJob.

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

Scénarios de cas d’usage

Les travaux élastiques peuvent être utilisés dans les scénarios suivants :

Automatiser des tâches de gestion à exécuter selon une planification spécifique
Déployer des modifications de schéma
Déplacer des données
Collecter et agréger des données pour la création de rapports ou à d’autres fins
Charger des données à partir de Stockage Blob Azure
Configurer des travaux de manière à ce qu’ils s’exécutent sur une collection de bases de données de façon récurrente, par exemple pendant les heures creuses.
Traitement des données sur un grand nombre de bases de données, par exemple collecte des données de télémétrie. Les résultats sont ensuite compilés dans une table de destination unique à des fins d’analyse ultérieure.

Migrer des travaux SQL Agent vers des travaux élastiques

Bien qu’il soit possible de créer vos propres scripts pour migrer vos travaux SQL Agent vers des travaux élastiques, une option plus pratique est disponible. Il existe un script téléchargeable qui facilite la copie de travaux SQL Agent existants vers des travaux élastiques.

Le script est un outil qui automatise le processus de conversion de ces travaux, ce qui vous évite de devoir les recréer manuellement dans le nouvel environnement.

Le fichier est un dossier compressé qui contient le script et la documentation associée. Pour l’utiliser, vous devez télécharger le fichier et suivre les instructions.

Une fois que vous avez entré tous les paramètres listés dans les instructions, la liste des travaux s’affiche. Le script crée ensuite chaque travail individuellement dans un état désactivé, si du moins il n’existe pas déjà. Après la création d’un travail, les étapes sont ajoutées avec les mêmes ID, texte de commande, tentatives de nouvelle tentative et secondes d’intervalle de nouvelle tentative initiale. La base de données liée à l’étape de travail sera le groupe cible. Si le groupe cible n’existe pas, il est créé automatiquement. La copie n’inclut pas de planifications, d’alertes ni de notifications.

Migrer des travaux SQL Agent vers SQL Agent sur Azure

La migration de travaux d’un serveur SQL Server local vers Azure SQL Managed Instance ou SQL Server s’exécutant sur une machine virtuelle suit un processus qui devrait être familier à la plupart des administrateurs de base de données.

Dans notre scénario, supposez que nous avons migré notre serveur SQL Server local vers Azure SQL Managed Instance. Nous devons migrer et ajuster plusieurs travaux SQL Agent pour qu’ils fonctionnent en toute transparence dans l’environnement Azure.

Évaluer les dépendances : identifiez le travail SQL Agent que vous souhaitez migrer. Lister toutes les dépendances, telles que les serveurs liés, les informations d’identification et les bases de données, sur lesquelles le travail s’appuie
Scripter le travail SQL Agent : scriptez le travail SQL Agent sur le serveur SQL Server en tant que script SQL. Pour ce faire, cliquez avec le bouton droit sur le travail dans SQL Server Management Studio (SSMS) et sélectionnez « Script job as » -> « CREATE To » -> « Nouvelle fenêtre d’éditeur de requête ».
Modifier les dépendances de travail : passez en revue le script SQL et modifiez toutes les dépendances de travail qui ont pu changer en raison de la migration. Par exemple, si le travail référence un serveur lié ou un chemin de fichier sur le serveur local, mettez-le à jour pour qu’il corresponde au nouvel environnement.
Création de travail Azure SQL MI : ouvrez SSMS ou Azure Data Studio et connectez-vous à votre Azure SQL Managed Instance. Créez un travail SQL Agent à l’aide du script que vous avez généré.
Créer des dépendances sur Azure SQL MI : si votre travail SQL Agent s’appuie sur des serveurs liés ou des informations d’identification, créez-les dans l’environnement Azure SQL MI. Vérifiez qu’ils correspondent à la configuration du serveur SQL Server local.
Planifiez le travail : configurez la planification des travaux dans Azure SQL MI à l’aide de SQL Server Agent. Vous pouvez créer une planification et la lier au travail.
Test : testez soigneusement le travail SQL Agent dans l’environnement Azure SQL MI pour vous assurer qu’il s’exécute comme prévu. Vérifiez si des erreurs ou des problèmes peuvent survenir en raison de différences entre SQL Server local et Azure SQL MI.
Monitoring et maintenance : supervisez les performances du travail et vérifiez qu’il continue de répondre à vos besoins dans l’environnement Azure SQL MI. Ajustez les configurations ou planifications en fonction des besoins.