Partager via

Automatiser des tâches de gestion à l’aide de travaux SQL Agent dans Azure SQL Managed Instance

S’applique à :Azure SQL Managed Instance

À l’aide de SQL Server Agent dans AzureSQL Managed Instance, vous pouvez créer et planifier des travaux qui peuvent être exécutés régulièrement sur une ou plusieurs bases de données. Ces travaux SQL Agent exécutent des requêtes Transact-SQL (T-SQL) et effectuent des tâches de maintenance. Cet article décrit l’utilisation de SQL Agent pour SQL Managed Instance.

Notes

SQL Agent n’est pas disponible dans Azure SQL Database ou Azure Synapse Analytics. Par conséquent, nous vous recommandons l’automatisation de travaux avec des travaux élastiques.

Quand utiliser des travaux SQL Agent

Vous pouvez utiliser des travaux SQL Agent dans plusieurs scénarios :

  • Automatiser des tâches de gestion et les planifier pour qu’elles s’exécutent tous les jours ouvrés, en dehors des heures d’ouverture, etc.
    • Déployez les modifications de schéma, la gestion des informations d’identification, la collecte de données de performances ou la collecte de données de télémétrie de locataire (client).
    • Mettez à jour les données de référence (informations communes à toutes les bases de données) et chargez des données à partir du stockage Blob Azure. Consultez BULK_INSERT pour connaître les arguments utilisés pour s’authentifier auprès du stockage Blob Azure.
    • Effectuer les tâches de maintenance courantes, notamment DBCC CHECKDB pour garantir l’intégrité des données ou la maintenance des index pour améliorer les performances des requêtes. 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.
    • Collectez les résultats des requêtes à partir d’un ensemble de bases de données dans une table centrale en continu. Les requêtes de performances peuvent être exécutées en permanence et configurées pour déclencher davantage de tâches à exécuter.
  • Collecter des données de création de rapports
    • Agréger des données provenant d’une collection de bases de données dans une table de destination unique.
    • Exécuter des requêtes de traitement de données avec un temps d’exécution plus long sur un grand ensemble de bases de données, par exemple, la collection de télémétrie de client. Les résultats sont rassemblés dans une table de destination unique pour une analyse ultérieure.
  • Déplacements de données
    • Créez des travaux qui répliquent les modifications apportées à vos bases de données sur d’autres bases de données, ou qui collectent les mises à jour effectuées dans des bases de données distantes et appliquent les modifications à la base de données.
    • Créez des travaux qui chargent des données depuis ou vers vos bases de données avec SQL Server Integration Services (SSIS).

Travaux SQL Agent dans Azure SQL Managed instance

SQL Server Agent exécute des travaux SQL Agent utilisés pour l’automatisation des tâches dans SQL Managed Instance.

Les tâches SQL Agent sont un ensemble spécifique de scripts T-SQL pour votre base de données. 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 une instance locale ou sur plusieurs instances distantes. Un travail SQL Agent est un composant interne du moteur de base de données exécuté dans le service SQL Managed Instance.

Il existe plusieurs concepts clés dans les travaux SQL Agent :

  • Les étapes de travail sont un ensemble d’une ou de plusieurs étapes qui doivent être exécutées dans le travail. Pour chaque étape de travail, vous pouvez définir une stratégie de nouvelle tentative et l’action qui doit se produire si l’étape de travail réussit ou échoue.
  • Les planifications définissent quand le travail doit être exécuté.
  • Les notifications vous permettent de définir les règles utilisées pour avertir les opérateurs par e-mail une fois le travail terminé.

Étapes de travail

Les étapes du travail SQL Agent sont des séquences d’actions que SQL Agent doit exécuter. Chaque étape a une étape suivante qui doit être exécutée si l’étape réussit ou échoue, et un nombre défini de nouvelles tentatives en cas d’échec.

SQL Agent vous permet de créer différents types d’étapes de travail.

  • Transact-SQL étapes de travail qui exécutent un lot Transact-SQL unique sur la base de données.
  • Étapes de commande de système d’exploitation/PowerShell qui peuvent exécuter un script de système d’exploitation personnalisé.
  • Étapes de travail SSIS qui vous permettent de charger des données à l’aide du runtime SSIS.
  • Étapes de réplication qui peuvent publier des modifications de votre base de données vers d’autres bases de données.

Notes

Pour plus d’informations, consultez Utiliser Azure SQL Managed Instance avec SQL Server Integration Services (SSIS) dans Azure Data Factory.

La réplication transactionnelle permet de répliquer les modifications apportées aux tables dans d’autres bases de données SQL Managed Instance, Azure SQL Database ou SQL Server. Pour plus d’informations, consultez Configurer la réplication dans Azure SQL Managed Instance.

D’autres types d’étapes de travail ne sont actuellement pas pris en charge dans SQL Managed Instance, comme la réplication de fusion et le lecteur de file d’attente.

Calendriers de travaux

Une planification spécifie quand un travail s’exécute. Plusieurs travaux peuvent s’exécuter sur la même planification, et plusieurs planifications peuvent appliquer le même travail.

Une planification peut définir les conditions suivantes pour l’heure d’exécution d’un travail :

  • Démarrez chaque fois que SQL Server Agent démarre. La tâche est déclenchée après chaque basculement.
  • Démarrez une fois, à une date et une heure spécifiques, ce qui est utile pour l’exécution différée d’un travail.
  • Démarrez selon une planification périodique.

Pour plus d’informations sur la planification d’un travail SQL Agent, consultez Planifier un travail.

Notes

Actuellement, Azure SQL Managed Instance ne vous permet pas de démarrer un travail lorsque le processeur est inactif.

Notifications pour les travaux

Les travaux SQL Agent vous permettent de recevoir des notifications lorsque le travail se termine avec succès ou lorsqu’il échoue. Vous pouvez recevoir des notifications par e-mail.

Si elle n’est pas déjà activée, vous devez d’abord configurer la fonctionnalité Database Mail sur SQL Managed Instance :

GO
EXEC sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
EXEC sp_configure 'Database Mail XPs', 1;
GO
RECONFIGURE

Par exemple, configurez un compte de messagerie pour l’envoi des notifications par e-mail. Affectez le compte au profil d’e-mail appelé AzureManagedInstance_dbmail_profile. Pour envoyer un e-mail à l’aide de travaux SQL Agent dans SQL Managed Instance, il doit exister un profil appelé AzureManagedInstance_dbmail_profile. Sinon, SQL Managed Instance ne peut pas envoyer d’e-mails via SQL Agent.

Notes

Pour le serveur de messagerie, nous vous recommandons d’utiliser les services de relais SMTP (Simple Mail Transfer Protocol) authentifiés pour envoyer un e-mail. Ces services de relais se connectent généralement via les ports 25 ou 587 pour les connexions TLS (Transport Layer Security), ou le port 465 pour les connexions SSL, mais la messagerie de base de données peut être configurée pour utiliser n’importe quel port. Ces ports requièrent une nouvelle règle de trafic sortant dans le groupe de sécurité réseau de votre instance managée. Ces services servent à maintenir la réputation des adresses IP et des domaines afin de réduire la possibilité que des domaines externes rejettent vos messages ou les placent dans le dossier des courriers indésirables. Envisagez un service de relais SMTP authentifié déjà sur vos serveurs locaux. Dans Azure, SendGrid est un service de relais SMTP, mais il en existe d’autres.

Utilisez l’exemple de script suivant pour créer un compte et un profil Database Mail, puis les associer :

-- Create a Database Mail account
EXECUTE msdb.dbo.sysmail_add_account_sp
    @account_name = 'SQL Agent Account',
    @description = 'Mail account for Azure SQL Managed Instance SQL Agent system.',
    @email_address = '$(loginEmail)',
    @display_name = 'SQL Agent Account',
    @mailserver_name = '$(mailserver)' ,
    @username = '$(loginEmail)' ,
    @password = '$(password)';

-- Create a Database Mail profile
EXECUTE msdb.dbo.sysmail_add_profile_sp
    @profile_name = 'AzureManagedInstance_dbmail_profile',
    @description = 'E-mail profile used for messages sent by Managed Instance SQL Agent.';

-- Add the account to the profile
EXECUTE msdb.dbo.sysmail_add_profileaccount_sp
    @profile_name = 'AzureManagedInstance_dbmail_profile',
    @account_name = 'SQL Agent Account',
    @sequence_number = 1;

Testez la configuration de la messagerie de base de données via T-SQL à l’aide de la procédure stockée système sp_send_dbmail :

DECLARE @body VARCHAR(4000) = 'The email is sent from ' + @@SERVERNAME;
EXEC msdb.dbo.sp_send_dbmail
    @profile_name = 'AzureManagedInstance_dbmail_profile',
    @recipients = 'ADD YOUR EMAIL HERE',
    @body = 'Add some text',
    @subject = 'Azure SQL Instance - test email';

Vous pouvez notifier l’opérateur que quelque chose s’est produit avec vos travaux SQL Agent. Un opérateur définit les informations de contact d’une personne responsable de la maintenance d’une ou plusieurs instances dans SQL Managed Instance. Parfois, les responsabilités d’opérateur sont affectées à une seule personne.

Dans les environnements avec plusieurs instances managées SQL ou instances SQL Server, de nombreuses personnes peuvent partager des 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é. Dans l’idéal, un opérateur n’est pas un individu dont les responsabilités peuvent changer, mais un groupe de distribution de courrier électronique.

Vous pouvez créer des opérateurs avec SQL Server Management Studio (SSMS) ou le script Transact-SQL illustré dans l’exemple suivant :

EXEC msdb.dbo.sp_add_operator
    @name=N'AzureSQLTeam',
    @enabled=1,
    @email_address=N'AzureSQLTeamn@contoso.com';

Vérifiez la réussite ou l’échec de l’e-mail par le biais du journal Database Mail dans SSMS.

Vous pouvez modifier n’importe quel travail SQL Agent et affecter des opérateurs avertis par e-mail si le travail se termine, échoue ou réussit. Modifiez le travail à l’aide de SSMS ou du script T-SQL suivant :

EXEC msdb.dbo.sp_update_job @job_name=N'Load data using SSIS',
    @notify_level_email=3, -- Options are: 1 on succeed, 2 on failure, 3 on complete
    @notify_email_operator_name=N'AzureSQLTeam';

Historique des travaux

SQL Managed Instance ne vous permet actuellement pas de modifier les propriétés de SQL Agent, car elles sont stockées dans les valeurs de Registre sous-jacentes. Cela signifie que les options d’ajustement de la stratégie de rétention de l’Agent pour les enregistrements d’historique des travaux sont fixes à la valeur par défaut de 1 000 enregistrements totaux et à un maximum de 100 enregistrements d’historique par travail.

Pour plus d’informations, consultez Consulter l’historique des travaux SQL Agent.

Appartenance au rôle de base de données

Si les utilisateurs liés à des connexions sans droits administrateur sont ajoutés à l’un des trois rôles fixes de base de données SQL Agent dans la base de données système msdb, il existe un problème dans lequel des autorisations doivent être explicitement accordées à trois procédures stockées système dans la base de données master. Si ce problème se produit, le message d’erreur The EXECUTE permission was denied on the object <object_name> (Microsoft SQL Server, Error: 229) s’affiche.

Une fois que vous avez ajouté des utilisateurs à un rôle de base de données fixe SQL Agent (SQLAgentUserRole, SQLAgentReaderRole ou SQLAgentOperatorRole) dans msdb, pour chacune des connexions de l’utilisateur ajoutées à ces rôles, exécutez le script T-SQL suivant pour accorder EXECUTE explicitement des autorisations aux procédures stockées système répertoriées. Cet exemple suppose que le nom d’utilisateur et le nom de connexion sont identiques :

USE [master]
GO
CREATE USER [login_name] FOR LOGIN [login_name];
GO
GRANT EXECUTE ON master.dbo.xp_sqlagent_enum_jobs TO [login_name];
GRANT EXECUTE ON master.dbo.xp_sqlagent_is_starting TO [login_name];
GRANT EXECUTE ON master.dbo.xp_sqlagent_notify TO [login_name];

Limitations des travaux SQL Agent dans SQL Managed instance

Il est important de noter les différences entre SQL Agent disponible dans SQL Server et dans le cadre de SQL Managed Instance. Pour plus d’informations sur les différences entre SQL Server et SQL Managed Instance au sujet des fonctionnalités prises en charge, consultez Différences T-SQL entre Azure SQL Managed Instance et SQL Server.

Certaines fonctionnalités de SQL Agent disponibles dans SQL Server ne sont pas prises en charge dans SQL Managed Instance :

  • Les paramètres de l’Agent SQL sont en lecture seule.
    • La procédure stockée du système sp_set_agent_properties n’est pas prise en charge.
  • L’activation/la désactivation de SQL Agent n’est actuellement pas prise en charge. L’Agent SQL est toujours en cours d’exécution.
  • Bien que les notifications soient partiellement prises en charge, les éléments suivants ne sont pas pris en charge :
    • Le pager n’est pas pris en charge.
    • NetSend n’est pas pris en charge.
    • Les alertes ne sont pas prises en charge.
  • Les proxys ne sont pas pris en charge.
  • Eventlog n’est pas pris en charge.
  • Le déclencheur de planification des tâches basé sur un processeur inactif n’est pas pris en charge.
  • Les étapes des tâches de réplication de fusion ne sont pas prises en charge.
  • Le lecteur de file d’attente n’est pas pris en charge.
  • Analysis Services n’est pas pris en charge.
  • L’exécution d’un script stocké en tant que fichier sur disque n’est pas prise en charge.
  • L’importation de modules externes, tels que dbatools et dbachecks, n’est pas prise en charge.
  • PowerShell Core n’est pas pris en charge.

Contenu connexe

  • Last updated on