Partager via


Agent de SQL Server

s’applique à :SQL ServerAzure SQL Managed Instance

Cet article fournit une vue d’ensemble de SQL Server Agent, qui est un service Microsoft Windows qui exécute des tâches d’administration planifiées (appelées tâches) dans SQL Server et Azure SQL Managed Instance.

Importante

Sur Azure SQL Managed Instance, la plupart, mais pas toutes les fonctionnalités de SQL Server Agent sont actuellement prises en charge. Pour plus d’informations, consultez différences T-SQL entre Azure SQL Managed Instance et SQL Server ou limitations des tâches de SQL Agent dans SQL Managed Instance.

Avantages de SQL Server Agent

SQL Server Agent utilise SQL Server pour stocker des informations sur les travaux. Les travaux contiennent une ou plusieurs étapes de travail. Chaque étape contient sa propre tâche, par exemple, la sauvegarde d'une base de données.

SQL Server Agent peut exécuter un travail selon une planification, en réponse à un événement spécifique ou sur demande. Par exemple, si vous sauvegardez l’ensemble des serveurs de l’entreprise chaque jour ouvrable après les horaires de bureau, vous pouvez automatiser cette tâche. Planifiez l’exécution de la sauvegarde après 22h00 du lundi au vendredi. Si la sauvegarde rencontre un problème, SQL Server Agent peut enregistrer l’événement et vous en avertir.

Remarque

Par défaut, le service SQL Server Agent est désactivé quand SQL Server est installé, sauf si l’utilisateur choisit explicitement de démarrer automatiquement le service.

Composants de SQL Server Agent

SQL Server Agent utilise les composants ci-après pour définir les tâches à exécuter et quand, et pour signaler si elles ont réussi ou échoué.

Utilisez le Gestionnaire de configuration SQL Server pour gérer le service SQL Server Agent et utiliser SQL Server Management Studio (SSMS) pour gérer facilement les propriétés, les tâches, les alertes, les opérateurs et les proxys SQL Server Agent dans une interface utilisateur graphique.

Emplois

Un travail est une série d’actions spécifiées effectuées par SQL Server Agent. Utilisez des travaux pour définir une tâche d’administration qui peut être exécutée une ou plusieurs fois, et dont la réussite ou l’échec sont surveillés. Un travail peut s’exécuter sur un serveur local ou sur plusieurs serveurs distants.

Importante

Les travaux sql Server Agent qui s’exécutent au moment d’un événement de basculement sur une instance de cluster de basculement SQL Server ne reprendnt pas après le basculement vers un autre nœud de cluster de basculement. Les travaux SQL Server Agent qui s’exécutent au moment où un nœud Hyper-V est suspendu ne reprendnt pas si la pause provoque un basculement vers un autre nœud. Les travaux qui commencent mais ne sont pas terminés en raison d’un événement de basculement sont enregistrés comme démarrés, mais n’affichent pas d’entrées de journal supplémentaires pour l’achèvement ou l’échec. Les travaux de SQL Server Agent dans ces scénarios semblent ne jamais se terminer.

Vous pouvez exécuter des tâches de plusieurs manières :

  • en fonction d'une ou plusieurs planifications ;
  • en réponse à une ou plusieurs alertes ;
  • En exécutant la procédure stockée sp_start_job.

Chaque action d'un travail est appelée étape du travail. Par exemple, une étape de travail peut consister à exécuter une instruction Transact-SQL, à exécuter un package SQL Server Integration Services (SSIS) ou à émettre une commande sur un serveur Analysis Services. Les étapes d'une tâche sont gérées dans le cadre d'un processus.

Chaque étape s'exécute dans un contexte de sécurité spécifique. Pour les étapes de travail qui utilisent Transact-SQL, utilisez l’instruction EXECUTE AS pour définir le contexte de sécurité de l’étape de travail. Pour les autres types d'étapes de travail, utilisez un compte proxy pour définir le contexte de sécurité de l'étape.

Utilisez la procédure stockée système sp_help_job pour obtenir des informations sur une tâche spécifique. Utilisez la table système dbo.sysjobs pour afficher des informations sur les tâches. Par exemple, utilisez l’instruction Transact-SQL (T-SQL) suivante pour afficher des informations sur tous les travaux sur un serveur :

USE msdb;
GO

SELECT job_id,
       [name]
FROM dbo.sysjobs;

Horaires

Une planification spécifie quand un travail s’exécute. Plusieurs tâches peuvent s'exécuter selon la même planification, et plusieurs planifications peuvent s'appliquer à la même tâche. Une planification peut définir les conditions suivantes pour l’heure d’exécution d’un travail :

  • Chaque fois que SQL Server Agent démarre.
  • Chaque fois que l’utilisation du processeur de l’ordinateur est au niveau que vous avez défini comme inactif.
  • Une fois, à une date et une heure spécifiques.
  • Selon une planification récurrente.

Pour plus d’informations, consultez Créer et attacher des planifications à des travaux.

Alertes

Une alerte est une réponse automatique à un événement donné. Par exemple, un événement peut être un travail qui démarre ou des ressources système qui atteignent un seuil spécifique. Vous définissez les conditions selon lesquelles une alerte est déclenchée.

Une alerte peut être une réponse à :

  • Événements SQL Server
  • Conditions de performance SQL Server
  • Des événements Microsoft Windows Management Instrumentation (WMI) sur l'ordinateur où SQL Server Agent est en cours d'exécution.

Une alerte peut :

  • prévenir un ou plusieurs opérateurs ;
  • Exécuter une tâche

Pour plus d’informations, consultez Alertes.

Opérateurs

Un opérateur définit les informations de contact pour une personne responsable de la maintenance d’une ou plusieurs instances de SQL Server. Dans certaines sociétés, les responsabilités d'opérateur sont affectées à une seule personne. Dans les entreprises qui ont de nombreux serveurs, plusieurs personnes peuvent se partager les responsabilités d'opérateur. Un opérateur ne contient pas d’informations de sécurité et ne définit pas de principal de sécurité.

SQL Server peut notifier les opérateurs d’alertes via :

  • Courriel
  • Récepteur de radiomessagerie (via e-mail)
  • net send

Remarque

Pour envoyer des notifications en utilisant net send, le service Windows Messenger doit être actif sur l’ordinateur où SQL Server Agent se trouve.

Importante

Les options d’envoi de page et net seront supprimées de SQL Server Agent dans une version ultérieure de SQL Server. Évitez d’utiliser ces fonctionnalités dans le nouveau travail de développement et prévoyez de modifier les applications qui utilisent actuellement ces fonctionnalités.

Pour envoyer des notifications aux opérateurs par e-mail ou par radiomessagerie, vous devez configurer SQL Server Agent pour qu’il utilise Database Mail. Pour plus d’informations, consultez Messagerie de base de données.

Un opérateur peut être l'alias d'un groupe d'individus. De cette manière, tous les membres de cet alias ne sont pas vérifiés en même temps. Pour plus d’informations, consultez Opérateurs.

Sécurité pour l'administration de SQL Server Agent

SQL Server Agent utilise l’un des rôles de base de données fixes suivants dans la msdb base de données pour contrôler l’accès à SQL Server Agent pour les utilisateurs qui ne sont pas membres du rôle serveur fixe sysadmin .

  • SQLAgentUserRole
  • SQLAgentReaderRole
  • SQLAgentOperatorRole

Outre ces rôles de base de données fixes, les sous-systèmes et les proxys aident les administrateurs de base de données à garantir que chaque étape de travail est exécutée avec les autorisations minimales nécessaires à la réalisation de cette tâche.

Rôles

Les membres des rôles de base de données fixes SQLAgentUserRole, SQLAgentReaderRole, et SQLAgentOperatorRole de msdb et les membres du rôle de serveur fixe sysadmin ont accès à SQL Server Agent. Un utilisateur qui n’appartient à aucun de ces rôles ne peut pas utiliser SQL Server Agent. Pour plus d’informations sur les rôles utilisés par SQL Server Agent, consultez Implémenter la sécurité de SQL Server Agent.

Sous-systèmes

Un sous-système est un objet prédéfini qui représente la fonctionnalité disponible pour une étape de travail. Chaque proxy a accès à un ou plusieurs sous-systèmes. Les sous-systèmes assurent la sécurité en délimitant l'accès aux fonctionnalités mises à la disposition d'un proxy. Chaque étape de travail s’exécute dans le contexte d’un proxy, à l’exception des étapes de travail Transact-SQL. Transact-SQL étapes du travail utilisent la EXECUTE AS commande pour définir le contexte de sécurité sur le propriétaire du travail.

SQL Server définit les sous-systèmes listés dans le tableau suivant :

Nom du sous-système Descriptif
Script Microsoft ActiveX Exécuter une étape de travail de script ActiveX.

Avertissement Le sous-système de script ActiveX sera supprimé de SQL Server Agent dans une version future de Microsoft SQL Server. Évitez d'utiliser cette fonctionnalité dans de nouveaux travaux de développement, et prévoyez de modifier les applications qui utilisent actuellement cette fonctionnalité.
Système d’exploitation (CmdExec) Permet de lancer un programme exécutable.
PowerShell Exécutez une tâche de script PowerShell.
Serveur de distribution de réplication Permet d’exécuter une étape de travail qui active l’Agent de distribution.
Fusion de réplication Permet d’exécuter une étape de travail qui active l’Agent de fusion.
Lecteur de file d’attente de réplication Permet d’exécuter une étape de travail qui active l’Agent de lecture de la file d’attente de réplication.
Instantané de réplication Permet d’exécuter une étape de travail qui active l’Agent d’instantané des réplications.
Lecteur du journal des transactions de réplication Permet d’exécuter une étape de travail qui active l’Agent de lecture du journal des réplications.
Commandes Analysis Services Exécuter une commande Analysis Services.
Requête Analysis Services Exécuter une requête Analysis Services.
Exécution de package SSIS Exécuter un package SSIS.

Remarque

Étant donné que Transact-SQL étapes de travail n’utilisent pas de proxys, il n’existe aucun sous-système SQL Server Agent pour Transact-SQL étapes de travail.

SQL Server Agent applique les restrictions des sous-systèmes même si le principal de sécurité du proxy a généralement l’autorisation d’exécuter cette tâche dans l’étape de travail. Par exemple, un proxy pour un utilisateur membre du rôle serveur fixe sysadmin ne peut pas exécuter une étape de travail SSIS, sauf si le proxy a accès au sous-système SSIS, même si l’utilisateur peut exécuter des packages SSIS.

Proxys

SQL Server Agent utilise des proxys pour gérer les contextes de sécurité. Un proxy peut être utilisé dans plusieurs étapes de travail. Les membres du rôle de serveur fixe sysadmin peuvent créer des proxys.

Chaque proxy correspond à des informations d’identification de sécurité. Chaque proxy peut être associé à un ensemble de sous-systèmes et de connexions. Le proxy peut être utilisé uniquement pour les étapes de travail qui utilisent un sous-système associé au proxy. Pour créer une étape de travail qui utilise un proxy spécifique, le propriétaire du travail doit utiliser une connexion associée à ce proxy ou un membre d’un rôle disposant d’un accès illimité aux proxys. Les membres du rôle de serveur fixe sysadmin disposent d'un accès sans restriction aux proxys.

Les membres de SQLAgentUserRole, SQLAgentReaderRole ou SQLAgentOperatorRole peuvent uniquement utiliser des proxys auxquels ils reçoivent un accès spécifique. Chaque utilisateur membre de l’un des rôles de base de données fixes de SQL Server Agent doit disposer d’un accès à des proxys spécifiques de façon à pouvoir créer les étapes de travail qui les utilisent.

Automatiser l'administration

Utilisez les étapes suivantes pour configurer SQL Server Agent de façon à automatiser l’administration de SQL Server :

  1. Identifiez les tâches administratives et les événements de serveur se produisant régulièrement et déterminez si ces tâches ou ces événements peuvent être administrés par programme. Une tâche convient à l'automatisation si elle implique une séquence d'étapes prévisibles et se produit à un moment spécifique ou en réponse à un événement particulier.

  2. Définissez un ensemble de travaux, de planifications, d’alertes et d’opérateurs en utilisant SQL Server Management Studio, des scripts Transact-SQL ou SQL Server Management Objects (SMO). Pour plus d’informations, consultez Créer des travaux.

  3. Exécutez les travaux SQL Server Agent que vous avez définis.

Remarque

Pour l’instance par défaut de SQL Server, le service SQL Server est nommé SQLSERVERAGENT. Pour les instances nommées, le service SQL Server Agent est nommé SQLAgent$nom_instance.

Si vous exécutez plusieurs instances de SQL Server, vous pouvez utiliser l’administration multiserveur pour automatiser des tâches courantes dans toutes les instances. Pour plus d’informations, consultez Administration automatisée à l’échelle d’une entreprise.

Utilisez les tâches suivantes pour démarrer avec SQL Server Agent :

Descriptif Article
Décrit comment configurer SQL Server Agent. Configurer l'agent SQL Server
Explique comment démarrer, arrêter et interrompre le service SQL Server Agent. Démarrer, arrêter ou suspendre le service SQL Server Agent
Décrit les considérations à prendre en compte lors de la spécification d'un compte pour le service SQL Server Agent. Sélectionner un compte pour le service SQL Server Agent
Explique comment utiliser le journal des erreurs de SQL Server Agent. Journal des erreurs du SQL Server Agent
Explique comment utiliser des objets de performances. Utiliser des objets de performance
Décrit l’Assistant Plan de maintenance, un utilitaire que vous utilisez pour créer des travaux, des alertes et des opérateurs afin d’automatiser l’administration d’une instance de SQL Server. Utiliser l'Assistant Plan de maintenance
Explique comment automatiser des tâches administratives à l'aide de l'Agent SQL Server. Tâches d'administration automatisée (Agent SQL Server)

NOSQLPS

À partir de SQL Server 2019, vous pouvez désactiver SQLPS. Sur la première ligne d’une étape de travail de type PowerShell, vous pouvez ajouter #NOSQLPS, ce qui empêche SQL Agent de charger automatiquement le module SQLPS. À présent, la tâche de votre SQL Agent exécute la version de PowerShell installée sur l’ordinateur, puis vous pouvez utiliser n’importe quel autre module PowerShell de votre choix.

Pour utiliser le module SqlServer à l’étape de la tâche de votre SQL Agent, vous pouvez placer ce code sur les deux premières lignes de votre script.

#NOSQLPS
Import-Module -Name SqlServer

Prise en charge du chiffrement TDS 8.0 et stricte

SQL Server 2025 (17.x) introduit la prise en charge de TDS 8.0 et TLS 1.3 pour SQL Server Agent, qui peut utiliser un chiffrement strict. SQL Server Agent découvre le niveau de chiffrement configuré dans le Gestionnaire de configuration SQL Server (Force Strict Encryptionou Force Encryptionaucun) et utilise l’option correspondante pour se connecter à SQL Server (strict, mandatoryou optional). Les travaux T-SQL DE SQL Agent qui se connectent à l’instance locale utilisent les paramètres de chiffrement de SQL Server Agent. Cela signifie que si SQL Server Agent se connecte au strict chiffrement, un travail T-SQL local se connecte également au même niveau de chiffrement.

Version TLS activée Gestionnaire de configuration SQL
Paramètre de configuration
Résultat attendu de SQL Server Agent Description
TLS 1.3 Forcer le chiffrement strict Connexion réussie et démarrage TDS 8.0 utilise strict chiffrement
TLS 1.3 Forcer le chiffrement Échec de la connexion et du démarrage TLS 1.3 nécessite strict
TLS 1.3 Aucun Échec de la connexion et du démarrage TLS 1.3 nécessite le strict chiffrement
TLS 1.2 Forcer le chiffrement strict Connexion réussie et démarrage TDS 8.0 peut utiliser TLS 1.2
TLS 1.2 Forcer le chiffrement Connexion réussie et démarrage TDS 7.x est utilisé pour assurer la connexion mandatory
TLS 1.2 Aucun Connexion réussie et démarrage TDS 7.x est utilisé pour assurer la connexion optional
TLS 1.3 et TLS 1.2 Forcer le chiffrement strict Connexion réussie et démarrage TDS 8.0 a utilisé le chiffrement strict
TLS 1.3 et TLS 1.2 Forcer le chiffrement Connexion réussie et démarrage TDS 7.x utilisé pour mandatory connexion
TLS 1.3 et TLS 1.2 Aucun Connexion réussie et démarrage TDS 7.x est utilisé pour assurer la connexion optional