Tâches élastiques dans Azure SQL Database

S’applique à :Azure SQL Database

Cet article passe en revue les fonctionnalités et les détails des travaux élastiques pour Azure SQL Database.

• Pour un tutoriel sur la configuration des tâches élastiques, reportez-vous au tutoriel sur les tâches élastiques.
• En savoir plus sur les concepts d'automation dans les plateformes de base de données Azure.

Aperçu des tâches élastiques

Vous pouvez créer et planifier des travaux élastiques qui s’exécutent régulièrement sur une ou plusieurs bases de données Azure SQL. Les travaux exécutent des requêtes Transact-SQL (T-SQL) et effectuent des tâches de maintenance.

Vous pouvez définir des bases de données cibles ou des groupes de bases de données où le travail s’exécute. Vous pouvez également définir des planifications pour l’exécution d’un travail. Toutes les dates et heures mentionnées pour les tâches élastiques se rapportent au fuseau horaire UTC.

Un processus gère la tâche d’authentification auprès de la base de données cible. Vous définissez, gérez et conservez également des scripts Transact-SQL pour qu’ils s’exécutent sur un groupe de bases de données.

Chaque travail enregistre l’état de l’exécution et retente automatiquement les opérations en cas d’échec.

Quand utiliser des travaux élastiques ?

Utilisez l’automatisation des travaux élastiques dans les scénarios suivants :

• Automatisez les tâches de gestion et planifiez-les pour qu’elles s’exécutent tous les jours de la semaine ou après les heures, par exemple.
  • Déployez les modifications de schéma et gérez les informations d’identification.
  • Collectez les journaux de données de performances ou les journaux du locataire (client).
  • Mettre à jour les données de référence (informations communes à toutes les bases de données).
  • Charger des données à partir du stockage Blob Azure
• Configurez les travaux pour qu’ils s’exécutent sur une collection de bases de données périodiques, comme pendant les heures creuses.
  • Collecter les résultats de la requête à partir d'un ensemble de bases de données dans une table centrale sur une base continue.
  • Les requêtes peuvent continuellement s’exécuter et être configurées pour déclencher des tâches supplémentaires.
• Collecter des données pour les rapports
  • Agréger des données provenant d’une collection de bases de données dans une table de destination unique.
  • Exécutez des requêtes de traitement des données sur un grand ensemble de bases de données, par exemple la collecte des journaux des clients. Les résultats sont rassemblés dans une table de destination unique pour une analyse ultérieure.
• Déplacement des données
  • Pour des solutions développées et personnalisées, l'automatisation des opérations ou d'autres formes de gestion des tâches.
  • Traitement ETL pour extraire, transformer et charger des données entre des tables d’une base de données.

Envisagez d'utiliser des tâches élastiques lorsque vous :

• Avoir une tâche qui doit s’exécuter régulièrement selon une planification, ciblant une ou plusieurs bases de données.

• Avoir une tâche qui doit s’exécuter une seule fois, mais sur plusieurs bases de données.

• devez exécuter des tâches sur toute combinaison de bases de données : une ou plusieurs bases de données individuelles, toutes les bases de données sur un serveur, toutes les bases de données dans un pool élastique, avec la flexibilité supplémentaire d'inclure ou d'exclure une base de données spécifique. Les travaux peuvent s’exécuter sur plusieurs serveurs, plusieurs pools et même sur des bases de données dans différents abonnements. Les serveurs et les pools sont énumérés dynamiquement au moment de l’exécution, ce qui permet aux travaux de s’exécuter sur toutes les bases de données présentes dans le groupe cible au moment de l’exécution.

  • Cette fonctionnalité est une différenciation significative de SQL Agent, qui ne peut pas énumérer dynamiquement les bases de données cibles, en particulier dans les scénarios clients SaaS où les bases de données sont ajoutées ou supprimées dynamiquement.

Composants des tâches élastiques

Composant	Description
Agent de tâches scalable	Ressource Azure que vous créez pour exécuter et gérer des travaux.
Base de données de travaux	Base de données dans Azure SQL Database utilisée par l’agent de travail pour stocker les données liées aux travaux, les définitions de travaux, etc.
Travail	Un travail est une unité de travail composée d’une ou plusieurs étapes de travail. Les étapes du travail spécifient le script T-SQL à exécuter et d’autres détails requis.
Groupe cible	Ensemble de serveurs, de pools et de bases de données sur lesquels un travail s’exécute.

Agent d'emploi élastique

Un agent de tâche élastique est la ressource Azure qui permet de créer, d'exécuter et de gérer des tâches. Vous créez l’agent de travail élastique en tant que ressource Azure dans le portail (Créer et gérer des travaux élastiques à l’aide de PowerShell et de l’API REST sont également pris en charge).

La création d'un agent de tâche élastique nécessite l'existence d'une base de données dans Azure SQL Database. L'agent configure cette base de données Azure SQL existante comme base de données de tâches.

Vous pouvez démarrer, désactiver ou annuler une tâche à travers le portail Azure. Le portail Azure vous permet également d'afficher les définitions des tâches et l'historique d'exécution.

Coût de l'agent de tâche élastique

La base de données de travaux est facturée au même tarif que les autres bases de données dans Azure SQL Database. Le coût de l’agent de travail élastique est basé sur la tarification fixe du niveau de service que vous sélectionnez pour l’agent de travail. Pour plus d’informations, consultez la page de tarification d’Azure SQL Database.

Base de données de travaux élastiques

Utilisez la base de données de travaux pour définir des travaux et suivre l’état et l’historique des exécutions de travaux. Les travaux s’exécutent dans les bases de données cibles. La base de données des tâches stocke également les métadonnées de l’agent, les journaux, les résultats et les définitions des tâches. Il contient de nombreuses procédures stockées utiles et d’autres objets de base de données pour la création, l’exécution et la gestion des travaux à l’aide de T-SQL.

Vous avez besoin d’azure SQL Database pour créer un agent de travail élastique. L’agent de travail stocke toutes ses métadonnées liées aux travaux dans la base de données de travaux, qui doit être une nouvelle base de données Azure SQL vide.

L’objectif de service recommandé de la base de données de travaux est DTU S1 ou supérieur, mais le choix optimal dépend des besoins de performances de vos travaux : le nombre d’étapes de travail, le nombre de cibles de travail et la fréquence d’exécution des travaux.

Si les opérations sur la base de données de tâches sont plus lentes que prévu, surveillez les performances de la base de données et l’utilisation des ressources dans la base de données de tâches, pendant les périodes de lenteur, en utilisant le portail Azure ou la vue de gestion dynamique sys.dm_db_resource_stats. Si l’utilisation d’une ressource, telle que le processeur, les E/S de données ou l’écriture de journal, approche 100 % et correspond aux périodes de lenteur, envisagez de mettre la base de données à l’échelle de manière incrémentielle pour atteindre des objectifs de service plus élevés (dans le modèle d’achat DTU ou dans le modèle d’achat vCore) jusqu’à ce que les performances de la base de données de travaux soient satisfaisantes.

La base de données des tâches elle-même peut être la cible d'une tâche élastique. Dans ce scénario, traitez la base de données de travail comme n’importe quelle autre base de données cible. Vous devez créer l’utilisateur du travail et accorder des autorisations suffisantes dans la base de données de travaux. Les informations d’identification limitées à la base de données pour l'utilisateur de l'emploi doivent également exister dans la base de données de l'emploi, tout comme elles existent pour toute autre base de données cible.

Lorsque la base de données de travaux est une cible d’un travail, assurez-vous que vos travaux ne modifient ni ne suppriment aucune métadonnées spécifique à l’agent de travail stockée dans cette base de données. Utilisez uniquement des procédures stockées ou des vues de travail pour modifier ou interroger des informations relatives aux travaux.

Important

Ne modifiez pas les objets existants ou ne créez pas de nouveaux objets dans la base de données de travaux, bien que vous puissiez lire les tables pour la création de rapports et l’analytique.

Travaux élastiques et étapes de travail

Un travail est une unité de travail qui s’exécute selon une planification ou en tant que travail unique. Un travail est constitué d’une ou plusieurs étapes de travail.

Chaque étape de travail spécifie un script T-SQL à exécuter, un ou plusieurs groupes cibles pour exécuter le script T-SQL et les informations d’identification dont l’agent de travail doit se connecter à la base de données cible. Chaque étape de travail est associée à un délai d’expiration et à des stratégies de nouvelle tentative personnalisables, et peut éventuellement spécifier des paramètres de sortie.

Cibles de tâches élastiques

Les travaux élastiques peuvent exécuter un ou plusieurs scripts T-SQL en parallèle, sur un grand nombre de bases de données, selon une planification ou à la demande. L'objectif peut être n'importe quel niveau d'Azure SQL Database.

Vous pouvez exécuter des travaux planifiés sur n’importe quelle combinaison de bases de données : une ou plusieurs bases de données individuelles, toutes les bases de données sur un serveur ou toutes les bases de données d’un pool élastique, avec la flexibilité supplémentaire d’inclure ou d’exclure une base de données spécifique. Les tâches peuvent s’exécuter sur plusieurs serveurs et plusieurs pools, et peuvent même s’exécuter sur des bases de données dans différents abonnements. Les serveurs et les pools sont énumérés dynamiquement au moment de l’exécution, ce qui permet aux travaux de s’exécuter sur toutes les bases de données présentes dans le groupe cible au moment de l’exécution.

L’image suivante montre un agent de travail qui exécute des travaux sur les différents types de groupes cibles :

Groupe cible

Un groupe cible définit l’ensemble de bases de données où s’exécute une étape de travail. Un groupe cible peut contenir n’importe quel nombre et combinaison des types suivants :

• Serveur SQL logique : si vous spécifiez un serveur, toutes les bases de données qui existent dans le serveur au moment de l’exécution du travail font partie du groupe. Vous devez fournir les informations d’identification de la master base de données afin que le groupe puisse être énuméré et mis à jour avant l’exécution du travail. Pour plus d’informations sur les serveurs logiques, consultez Qu’est-ce qu’un serveur logique dans Azure SQL Database et Azure Synapse ?

• Pool élastique : si vous spécifiez un pool élastique, toutes les bases de données qui se trouvent dans le pool élastique au moment de l’exécution du travail font partie du groupe. Comme avec un serveur, vous devez fournir les master informations d’identification de la base de données afin que le groupe puisse être mis à jour avant l’exécution du travail.

• Base de données unique : spécifiez une ou plusieurs bases de données individuelles à faire partie du groupe.

Conseil

Au moment de l’exécution du travail, l’énumération dynamique réévalue l’ensemble de bases de données dans les groupes cibles qui incluent des serveurs ou des pools. L’énumération dynamique garantit que les travaux s’exécutent sur toutes les bases de données qui existent dans le serveur ou le pool au moment de l’exécution du travail. La réévaluation de la liste des bases de données au moment de l’exécution est utile pour les scénarios où l’appartenance au pool ou au serveur change fréquemment.

Les pools et les bases de données uniques peuvent être inclus ou exclus du groupe. Vous pouvez créer un groupe cible avec n’importe quelle combinaison de bases de données. Par exemple, vous pouvez ajouter un serveur à un groupe cible, mais exclure certaines bases de données d’un pool élastique (ou exclure un pool entier).

Un groupe cible peut inclure des bases de données dans plusieurs abonnements et dans plusieurs régions. Les exécutions entre régions ont une latence plus élevée que celles au sein d'une même région.

Les exemples suivants montrent comment différentes définitions de groupe cible sont énumérées dynamiquement au moment de l’exécution du travail pour déterminer les bases de données à affecter :

• L’exemple 1 montre un groupe cible se composant d’une liste de bases de données individuelles. Lorsqu’une étape de travail utilise ce groupe cible, l’action de l’étape de travail s’exécute dans chacune de ces bases de données.

• L’exemple 2 montre un groupe cible qui contient un serveur comme cible. Lorsqu’une étape de travail utilise ce groupe cible, le serveur est énuméré dynamiquement pour déterminer la liste des bases de données actuellement présentes sur le serveur. L’action de l’étape de travail s’exécute dans chacune de ces bases de données.

• L’exemple 3 montre un groupe cible similaire à l’exemple 2, mais une base de données individuelle est explicitement exclue. L’action de l’étape de travail ne s’exécute pas dans la base de données exclue.

• L’exemple 4 montre un groupe cible qui contient un pool élastique comme cible. Comme dans l’exemple 2, le pool est énuméré dynamiquement au moment de l’exécution du travail pour déterminer la liste des bases de données dans le pool.

• L’exemple 5 et l’exemple 6 montrent des scénarios avancés où les serveurs, les pools élastiques et les bases de données peuvent être combinés avec des règles d’inclusion et d’exclusion.

Planifications de travaux élastiques

Les tâches élastiques sont des produits à priorité au cloud. Ils sont conçus pour démarrer même si un problème de disponibilité de réseau ou de service temporaire se produit lorsqu’ils sont planifiés. Les planifications de travaux élastiques tiennent compte de l’heure de début de la planification et des intervalles demandés. Lorsque vous créez une planification de travail élastique, le travail s’exécute dès que possible après chaque événement d’intervalle planifié.

Important

En guise de meilleure pratique, créez des planifications de travail qui commencent à l’avenir.

Les planifications de travaux détectent les événements manqués. Si vous créez une planification de tâche qui commence à une date passée, la tâche s’exécute immédiatement lorsqu’elle est activée. S’il est désactivé ou non disponible, le travail s’exécute immédiatement après avoir été activé ou rendu disponible.

Par exemple, il s’agit actuellement du 2 janvier 9 h UTC. Vous avez configuré une nouvelle tâche pour qu’elle commence ce soir, le 2 janvier à 22h30 (UTC), et s’exécute quotidiennement. La tâche s'exécute à 10 h 30 (UTC).

Pour empêcher un travail de démarrer accidentellement, créez des planifications qui démarrent à l’avenir. Dans un exemple qui peut entraîner un démarrage accidentel d’un travail, vous avez configuré un nouveau travail pour qu’il s’exécute quotidiennement à 10 h 30 UTC. Vous désactivez le travail pendant une semaine. Ensuite, si vous activez le travail à 8 h 30 UTC, le travail s’exécute immédiatement, rattrapant l’événement d’intervalle manqué qui doit avoir été exécuté la nuit dernière. Après son exécution, l’agent de travail ne s’exécute pas à nouveau tant que l’exécution planifiée suivante n’est pas terminée à 10 h 30 UTC. Pour empêcher l’exécution à 18 h 30 UTC dans ce scénario, mettez à jour le début de la planification du travail le 8 janvier à 10 h 30 UTC, puis activez le travail. Ou, activez la tâche à un moment où elle peut s’exécuter immédiatement.

Authentification

Choisissez une méthode pour toutes les cibles d'un agent de tâche élastique. Par exemple, pour un seul agent de travail élastique, vous ne pouvez pas configurer un serveur cible pour utiliser des informations d’identification délimitées à la base de données et une autre pour utiliser l’authentification d’ID Microsoft Entra.

L’agent de travail élastique peut se connecter aux serveurs et bases de données spécifiés par le groupe cible à l’aide de deux options d’authentification :

• Utilisez l'authentification Microsoft Entra (anciennement Azure Active Directory) avec une identité managée affectée par l'utilisateur (UMI).
• Utilisez des identifiants délimités au niveau de la base de données.

Authentification via identité gérée assignée par l'utilisateur (UMI)

L’authentification Microsoft Entra via l’identité managée affectée par l’utilisateur (UMI) est l’option recommandée pour connecter des travaux élastiques à Azure SQL Database. Avec la prise en charge de Microsoft Entra ID, l’agent de travail se connecte aux bases de données cibles (bases de données, serveurs, pools élastiques) et à la base de données de sortie à l’aide de l’UMI.

Si vous le souhaitez, vous pouvez activer l’authentification d’ID Microsoft Entra sur le serveur logique qui contient la base de données de travaux élastiques, pour accéder à cette base de données et l’interroger via les connexions d’ID Microsoft Entra. Toutefois, l’agent de travail utilise l’authentification interne basée sur des certificats pour se connecter à sa base de données de travail.

Vous pouvez créer une UMI ou utiliser une UMI existante et affecter la même UMI à plusieurs agents de tâche. Chaque agent de travail ne prend en charge qu’un seul UMI. Après avoir affecté un UMI à un agent de travail, l’agent de travail utilise cette identité pour se connecter et exécuter des travaux T-SQL sur les bases de données cibles. L’agent de travail n’utilise pas l’authentification SQL sur le serveur cible ou les bases de données.

Le nom UMI doit commencer par une lettre ou un nombre et avoir une longueur comprise entre 3 et 128 caractères. Il peut contenir des caractères de trait d’union (-) et de trait de soulignement (_).

Pour plus d’informations sur UMI dans Azure SQL Database, consultez Identités managées pour Azure SQL, notamment les étapes requises et les avantages de l’utilisation d’un UMI comme identité de serveur logique Azure SQL Database. Pour plus d’informations, consultez l’authentification Microsoft Entra pour Azure SQL.

Important

Lorsque vous utilisez l'authentification Microsoft Entra ID, créez votre utilisateur jobuser à partir de ce Microsoft Entra ID dans chaque base de données cible. Accordez à cet utilisateur les autorisations nécessaires pour exécuter vos travaux dans chaque base de données cible.

L’utilisation d’une identité managée affectée par le système n’est pas prise en charge.

Authentification par des identifiants liés à la base de données

Bien que l’authentification Microsoft Entra (anciennement Azure Active Directory) soit l’option recommandée, vous pouvez configurer des travaux pour utiliser des informations d’identification délimitées à la base de données pour se connecter aux bases de données spécifiées par le groupe cible lors de l’exécution. Avant octobre 2023, les informations d’identification délimitées à la base de données étaient la seule option d’authentification.

Si un groupe cible contient des serveurs ou des pools, ces identifiants délimités par la base de données se connectent à la base de données master afin d'énumérer les bases de données disponibles.

• Créez les informations d'identification au niveau de la base de données dans la base de données de travail.

• Toutes les bases de données cibles doivent disposer d'informations de connexion avec des autorisations suffisantes pour que l'exécution de la tâche réussisse (jobuser dans le diagramme suivant).

• Les informations d’identification que vous créez dans les bases de données cibles (LOGIN et PASSWORD pour masteruser et jobuser, dans le diagramme suivant) doivent correspondre à celles des IDENTITY et SECRET que vous créez dans la base de données de travail.

• Vous pouvez réutiliser les informations d’identification entre les travaux. Les mots de passe d’informations d’identification sont chiffrés et sécurisés contre les utilisateurs disposant d’un accès en lecture seule aux objets de tâche.

L’image suivante vous aide à comprendre comment configurer les informations d’identification de travail appropriées et comment l’agent de travail élastique se connecte à l’aide d’informations d’identification de base de données comme authentification pour les connexions et les utilisateurs dans les serveurs et bases de données cibles.

Note

Lorsque vous utilisez des informations d'identification délimitées à la base de données, n'oubliez pas de créer votre utilisateur jobuser dans chaque base de données cible.

Points de terminaison privés de tâches élastiques

L'agent de tâche élastique prend en charge les points de terminaison privés pour les tâches élastiques. La création d'un point de terminaison privé de tâches élastiques établit une liaison privée entre la tâche élastique et le serveur cible. La fonctionnalité de points de terminaison privés des tâches élastiques diffère d'Azure Private Link.

La fonctionnalité points de terminaison privés du travail élastique prend en charge les connexions privées aux serveurs cibles et de sortie, afin que l’agent de travail puisse les atteindre même lorsque l’option Refuser l’accès public est activée. L’utilisation de points de terminaison privés est également une solution possible si vous souhaitez désactiver l'option Autoriser les services et ressources Azure à accéder à ce serveur.

Les points de terminaison privés de tâches élastiques prennent en charge toutes les options d'authentification de l'agent de tâche élastique.

La fonctionnalité de point de terminaison privé de travail élastique vous permet de choisir un point de terminaison privé géré par le service pour établir une connexion sécurisée entre l’agent de travail et ses serveurs cible et de sortie. Un point de terminaison privé géré par le service est une adresse IP privée au sein d’un réseau et d’un sous-réseau virtuels spécifiques. Lorsque vous choisissez d’utiliser des points de terminaison privés sur l’un des serveurs cibles et de sortie de votre agent de travail, Azure crée un point de terminaison privé géré par le service. Ce point de terminaison privé est ensuite utilisé exclusivement par l’agent de travail pour la connexion et l’exécution de travaux, ou pour écrire la sortie du travail sur cette cible et les bases de données de sortie.

Vous pouvez créer et autoriser des points de terminaison privés de tâches élastiques via le portail Azure. Les serveurs cibles connectés via la liaison privée peuvent se trouver n'importe où dans Azure, même dans différentes zones géographiques et différents abonnements. Vous devez créer un point de terminaison privé pour chaque serveur cible souhaité et pour le serveur de sortie de tâche pour activer cette communication.

Pour obtenir un tutoriel sur la configuration d'un nouveau point de terminaison privé géré par le service pour les tâches élastiques, reportez-vous à Configurer un point de terminaison privé de tâches élastiques Azure SQL.

Configuration requise pour les points de terminaison privés de tâches élastiques

• Pour utiliser un point de terminaison privé de travaux élastiques, l’agent de tâches ainsi que les serveurs cibles ou les bases de données doivent être hébergés dans Azure (qu’ils soient dans des régions identiques ou différentes) et dans le même type de cloud (par exemple, tous deux dans le cloud public ou tous deux dans le cloud gouvernemental).

• Le Microsoft.Network fournisseur de ressources doit être enregistré auprès des abonnements hôtes de l’agent de travail ainsi que du serveur cible et du serveur de sortie.

• Azure crée des points de terminaison privés de travail élastiques par cible et serveur de sortie. Vous devez les approuver avant que l’agent de travail élastique puisse les utiliser. Vous pouvez les approuver via le volet Mise en réseau de ce serveur logique ou de votre client préféré. Ensuite, l’agent de travail élastique peut atteindre toutes les bases de données sous ce serveur à l’aide d’une connexion privée.

• La connexion de l’agent de travail élastique à la base de données de travaux n’utilise pas de point de terminaison privé. L'agent de tâche lui-même utilise l'authentification interne basée sur des certificats pour se connecter à sa base de données des tâches.

  • Si vous ajoutez la base de données de travaux en tant que membre de groupe cible, elle se comporte comme une cible régulière. Vous devez configurer avec un point de terminaison privé en fonction des besoins.

Autorisations de la base de données de travaux élastiques

Durant la création de l'agent de tâche, un schéma, des tables et un rôle appelé jobs_reader sont créés dans la base de données des tâches. Le rôle, créé avec l'autorisation suivante, est conçu pour permettre aux administrateurs de contrôler plus précisément les accès aux tâches à des fins de surveillance : Les administrateurs peuvent fournir aux utilisateurs la possibilité de surveiller l’exécution des travaux en les ajoutant au jobs_reader rôle dans la base de données de travaux.

Nom de rôle	Permissions de schéma jobs	Autorisations de schéma jobs_internal
jobs_reader	SELECT	Aucun(e)

Attention

Ne mettez pas à jour les vues de catalogue internes dans la base de données de travaux, telles que jobs.target_group_members. Les modifications manuelles de ces affichages catalogue peuvent endommager la base de données des tâches et provoquer une défaillance. Ces vues sont destinées à la consultation en lecture seule. Vous pouvez utiliser les procédures stockées sur votre base de données de travail pour ajouter ou supprimer des groupes cibles et des membres, tels que jobs.sp_add_target_group_member.

Tenez compte des implications en matière de sécurité avant d'accorder un niveau d'accès élevé à la base de données des tâches. Un utilisateur malveillant disposant d’autorisations pour créer ou modifier des travaux peut créer ou modifier un travail qui utilise des informations d’identification stockées pour se connecter à une base de données sous le contrôle de l’utilisateur malveillant. Cette vulnérabilité peut permettre à l’utilisateur malveillant de déterminer le mot de passe des informations d’identification ou d’exécuter des commandes malveillantes.

Surveiller des tâches élastiques

L’agent de travail élastique s’intègre aux alertes Azure pour les notifications d’état du travail, ce qui simplifie la solution pour surveiller l’état et l’historique de l’exécution du travail.

Le portail Azure inclut des fonctionnalités supplémentaires pour prendre en charge les travaux élastiques et la surveillance des travaux. Dans la page Vue d’ensemble de l’agent de travail élastique, les exécutions de travaux les plus récentes sont affichées, comme illustré dans la capture d’écran suivante.

Vous pouvez créer des règles d'alerte Azure Monitor avec Portail Azure, Azure CLI, PowerShell et API REST. La métrique Tâches élastiques ayant échoué est un bon point de départ pour surveiller et recevoir des alertes sur l'exécution de tâches élastiques. En outre, vous pouvez choisir d'être alerté par le biais d'une action configurable comme le SMS ou l'e-mail en installant Azure Alert. Pour plus d'informations, reportez-vous à Créer des alertes pour la base de données Azure SQL dans le portail Azure.

Pour un exemple, reportez-vous à Créer, configurer et gérer des tâches élastiques..

Résultat de la tâche

Le résultat des étapes d’un travail sur chaque base de données cible est enregistré en détail, et la sortie de script peut être capturée dans une table spécifiée. Vous pouvez indiquer une base de données pour enregistrer toutes les données retournées par une tâche.

Historique des travaux

Vous pouvez afficher l’historique d’exécution de travaux élastiques dans la base de données de travaux en interrogeant la table jobs.job_executions. Une tâche de nettoyage du système purge l'historique d'exécution datant de plus de 45 jours. Pour supprimer manuellement l’historique de moins de 45 jours, exécutez la sp_purge_jobhistory procédure stockée dans la base de données de travaux.

Statut de tâche

Vous pouvez surveiller l'exécution des tâches élastiques dans la base de données des tâches en interrogeant la table jobs.job_executions.

Bonnes pratiques

Tenez compte des meilleures pratiques suivantes lorsque vous utilisez des tâches de base de données élastique :

Bonnes pratiques de sécurité

• Limitez l'utilisation des API aux personnes de confiance.

• Accordez aux droits d'accès le minimum de privilèges nécessaires pour accomplir une tâche. Pour plus d'informations, consultez Autorisations et permissions.

• Lorsque vous utilisez un membre de groupe cible de serveur ou de pool, créez des informations d’identification distinctes avec des droits sur la master base de données pour afficher et répertorier les bases de données. Ces identifiants étendent les listes de bases de données des serveurs et pools avant l’exécution de la tâche.

Performance des tâches élastiques

Les tâches élastiques utilisent des ressources de calcul minimales dans l'attente de la finalisation des tâches de longue durée.

En fonction de la taille du groupe cible de bases de données et du délai d'exécution souhaité d'une tâche (nombre de workers simultanés), l'agent nécessite différents niveaux de calcul et de performance de la part de la base de données de tâches (plus le nombre de cibles et de tâches est élevé, plus les calculs nécessaires sont importants).

Niveaux de capacité concurrente

À compter d'octobre 2023, l'agent de tâche élastique dispose de plusieurs niveaux de performances pour permettre l'augmentation de la capacité.

Les incréments de capacité indiquent le nombre total de bases de données cibles simultanées auxquels l'agent de tâche peut se connecter et démarrer une tâche. Pour obtenir plus de connexions cibles simultanées pour l’exécution du travail, mettez à niveau le niveau d’un agent de travail à partir du niveau JA100 par défaut, qui a une limite de 100 connexions cibles simultanées.

La plupart des environnements nécessitent moins de 100 tâches simultanées à tout moment. Par conséquent, JA100 est la valeur par défaut.

Niveau de l’agent de travail élastique	Nombre maximal de travaux simultanés
JA100	100
JA200	200
JA400	400
JA800	800

Le dépassement du niveau de capacité d’accès concurrentiel de l’agent de travail avec des cibles de travail crée des retards de mise en file d’attente pour certaines bases de données et serveurs cibles. Par exemple, si vous démarrez une tâche avec 110 objectifs dans le niveau JA100, 10 objectifs attendent de commencer jusqu'à ce que d'autres aient fini.

Vous pouvez modifier le niveau ou l’objectif de service d’un agent de travail élastique via le portail Azure, PowerShell ou l’API REST Agents de travaux. Pour voir un exemple, reportez-vous à Mettre à l'échelle l'agent de travail.

Limiter l’effet du travail sur les pools élastiques

Pour vous assurer que les ressources ne sont pas surchargées lors de l’exécution de travaux sur des bases de données dans un pool élastique Azure SQL Database, configurez les travaux pour limiter le nombre de bases de données sur lesquelles un travail s’exécute en même temps.

Définissez le nombre de bases de données simultanées sur lesquelles un travail s’exécute en définissant le paramètre sp_add_jobstep de la procédure stockée @max_parallelismdans T-SQL.

Scripts idempotents

Les scripts T-SQL d’un travail élastique doivent être idempotents, autrement dit, si le script réussit et qu’il s’exécute à nouveau, le même résultat se produit. Un script peut échouer en raison de problèmes réseau passager. Dans ce cas, la tâche réessaie automatiquement d’exécuter le script un nombre prédéfini de fois avant de s'arrêter. Un script idempotent a le même résultat même s’il a été exécuté deux fois (ou plus).

Une tactique simple consiste à tester l’existence d’un objet avant de créer ce dernier. L’exemple suivant est hypothétique :

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 même, un script doit être capable d’exécuter avec succès par une vérification logique et s’adapter aux conditions qu’il rencontre.

Limites

Voici les limitations actuelles du service de tâches élastiques. L’équipe produit travaille activement à supprimer autant de ces limitations que possible.

Problème	Description
L'agent de tâche élastique doit être recréé et démarré dans la nouvelle région après une opération de basculement ou un déplacement vers une nouvelle région Azure.	Le service de tâches élastiques stocke l'ensemble de son agent de tâche et des métadonnées de tâches dans la base de données des tâches. Tout basculement ou déplacement de ressources Azure vers une nouvelle région Azure déplace également la base de données de travaux, l’agent de travail et les métadonnées de travail vers la nouvelle région Azure. Toutefois, l’agent de travail élastique est une ressource de calcul uniquement qui doit être recréée et démarrée explicitement dans la nouvelle région avant que les travaux ne commencent à s’exécuter à nouveau. Une fois démarré, l’agent de travail élastique reprend l’exécution de travaux dans la nouvelle région en fonction de la planification de travail définie précédemment.
Journaux d’audit SQL excessifs de la base de données de travaux	L'agent de tâches élastiques fonctionne en interrogeant constamment la base de données de tâches pour vérifier l'arrivée de nouvelles tâches et d'autres opérations CRUD. Si l’audit est activé sur le serveur qui héberge une base de données de travaux, la base de données de travaux peut générer un grand nombre de journaux d’audit. Vous pouvez atténuer ce problème en filtrant ces journaux d’audit à l'aide de la commande Set-AzSqlServerAudit avec une expression conditionnelle. Par exemple : Set-AzSqlServerAudit -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -BlobStorageTargetState Enabled -StorageAccountResourceId "/subscriptions/7fe3301d-31d3-4668-af5e-211a890ba6e3/resourceGroups/resourcegroup01/providers/Microsoft.Storage/storageAccounts/mystorage" -PredicateExpression "application_name <> 'Microsoft Azure SQL Database elastic jobs'" Cette commande filtre uniquement les journaux d’audit de l’agent de travail vers la base de données des tâches, et non pas les journaux d’audit de l’agent de travail vers les bases de données cibles.
Utilisation d'une base de données Hyperscale comme base de données de tâche	L'utilisation d'une base de données Hyperscale comme base de données de tâche n'est pas prise en charge. Toutefois, les travaux élastiques peuvent cibler des bases de données Hyperscale comme n’importe quelle autre base de données dans Azure SQL Database.
Bases de données serverless et mise en pause automatique avec des tâches élastiques.	La base de données serverless avec mise en pause automatique n'est pas prise en charge comme base de données de tâches. Les bases de données serverless ciblées par les travaux élastiques prennent en charge la suspension automatique et les connexions de travail les reprendnt.
Exporter une Base de données de travaux vers un fichier BACPAC	L’exportation d’une base de données de travaux vers un fichier BACPAC n’est pas prise en charge. Si le serveur SQL Server contenant une base de données de travail doit être exporté, supprimez d’abord la base de données de travaux avant d’exporter le serveur.

Étape suivante

Tutoriel – Créer, configurer et gérer des tâches élastiques

Contenu connexe

• Automatiser les tâches de gestion dans Azure SQL
• Créer et gérer des tâches élastiques à l’aide de PowerShell
• Créer et gérer des tâches élastiques à l'aide de T-SQL