Introduction
Un précédent article a été publié sur l’installation et la configuration de SQL Server 2019 sur Ubuntu 18.04 : Installation et configuration de Microsoft SQL Server 2019 sur Linux Ubuntu 18.04.
Et l’agent SQL Server sur Linux ? Oui il est présent, MAIS… il y a un inconvénient majeur décrit dans cet article.
Activation de l’agent SQL Server
Activer l’agent SQL Server est très facile : en tant que mssql
, lancer mssql-conf
pour mettre le paramètre
sqlagent.enabled
à true
mssql@vps$ /opt/mssql/bin/mssql-conf set sqlagent.enabled true
Ce paramètre est statique, le service mssql-server
doit être redémarré.
D’autres paramètres peuvent être personnalisés avant le redémarrage du service (verbosité du journal d’erreurs, fichier de log…) :
mssql@vps$ /opt/mssql/bin/mssql-conf set sqlagent.errorlogfile /opt/mssql/dba/srvmssql/log/sqlagent.log
mssql@vps$ /opt/mssql/bin/mssql-conf set sqlagent.errorlogginglevel 4
mssql@vps$ /opt/mssql/bin/mssql-conf set sqlagent.startupwaitforalldb 0
Redémarrer le service mssql-server
:
root@vps$ systemctl restart mssql-server
Dans le fichier de log de l’agent SQL :
2019-05-31 13:31:46 - ? [146] Request servicer engine started
2019-05-31 13:31:46 - ? [167] Populating job cache...
2019-05-31 13:31:46 - + [396] An idle CPU condition has not been defined - OnIdle job schedules will have no effect
2019-05-31 13:31:46 - ? [110] Starting SQLServerAgent Monitor using '' as the notification recipient...
2019-05-31 13:31:46 - ? [133] Support engine started
2019-05-31 13:31:47 - ? [168] There are 1 job(s) [0 disabled] in the job cache
2019-05-31 13:31:47 - ? [170] Populating alert cache...
2019-05-31 13:31:47 - ? [171] There are 0 alert(s) in the alert cache
2019-05-31 13:31:47 - ? [101] SQLServerAgent service successfully started
Il y a très peu de paramètres pour l’agent SQL Server, exécuter mssql-conf list
pour en avoir la liste :
mssql@vps$ /opt/mssql/bin/mssql-conf list | grep 'sqlagent'
sqlagent.databasemailprofile SQL Agent Database Mail profile name sqlagent.enabled Enable or disable SQLAgent sqlagent.errorlogfile SQL Agent log file path sqlagent.errorlogginglevel SQL Agent logging level bitmask - 1=Errors, 2=Warnings, 4=Info sqlagent.startupwaitforalldb Set to 1 (default) if SqlAgent should wait for all databases on startup; set to 0 to wait for MSDB only
Ces paramètres sont stockés dans la section sqlagent
du fichier /var/opt/mssql/mssql.conf
:
/var/opt/mssql/mssql.conf
[sqlagent]
enabled = true
errorlogfile = /opt/mssql/dba/srvmssql/log/sqlagent.log
errorlogginglevel = 4
startupwaitforalldb = 0
Inconvénients : sécurité, contrôle de l’agent SQL Server
Activé, les processus de l’agent SQL Server dans le moteur s’exécutent dans la base de données msdb
,
pas de différence par rapport à SQL Server sous Windows :
sqlcmd -Usa
exec sp_who2 go
51 ... NT AUTHORITY\NETWORK SERVICE vps msdb AWAITING COMMAND ... 05/31 11:24:49 SQLAgent - Generic Refresher 52 ... NT AUTHORITY\NETWORK SERVICE vps msdb AWAITING COMMAND ... 05/31 11:00:38 SQLAgent - Email Logger 56 ... NT AUTHORITY\NETWORK SERVICE vps msdb AWAITING COMMAND ... 05/31 11:25:01 SQLAgent - Job invocation engine
Maintenant premier problème : l’agent SQL Server s’exécute avec le login système prédéfini NT AUTHORITY\NETWORK SERVICE
lequel dispose du droit sysadmin
.
Il n’y a pas (pour le moment ?) de levier pour changer le compte de service de l’agent SQL Server.
Le second: comment redémarrer l’agent SQL Server sans devoir redémarrer le serveur MS SQL dans son intégralité ? Pour le moment, aucune solution,
le service mssql-server
doit être redémarré et c’est très problématique.
Peut-être que dans les prochaines versions ces 2 problèmes seront adressés, ces deux problèmes étant en fait intimement liés.
La désactivation/activation de l’agent SQL Server avec mssql-conf
ne fonctionne pas, puisqu’il s’agit d’un paramétrage statique le service
mssql-server
doit être redémarré.
En guise de solution de contournement, un test a été mené en tuant les sous-processus de l’agent SQL Server :
sqlcmd -Usa
kill 51 go kill 52 go kill 56 go
Test sans effet, l’agent SQL Server n’est pas en mesure de redémarrer proprement de lui-même et des erreurs en cascade se produisent. De toutes façons, cette solution n’est pas "clean".
2019-05-31 11:51:41 - ? [157] Refreshing schedule 8 (of job 0x00000000000000000000000000000000) for UPDATE [requested by: sa]
2019-05-31 11:51:41 - ! [298] SQLServer Error: 10054, TCP Provider: An existing connection was forcibly closed by the remote host. [SQLSTATE 08S01]
2019-05-31 11:51:41 - ! [298] SQLServer Error: 10054, Communication link failure [SQLSTATE 08S01]
2019-05-31 11:51:41 - ! [298] SQLServer Error: 16389, Communication link failure [SQLSTATE 08S01]
2019-05-31 11:51:41 - ! [298] SQLServer Error: 229, The EXECUTE permission was denied on the object 'sp_help_schedule', database 'msdb', schema 'dbo'. [SQLSTATE 42000]
2019-05-31 11:51:41 - ! [000] Failed to retrieve schedule 8 (for job 0x00000000000000000000000000000000) from the server
...
Construction et exécution d’un job
Pour la construction, la programmation et l’exécution des jobs, pas de différence par rapport à Windows, tout semble parfait avec les commandes T-SQL ou avec l’interface graphique SQL Server Management Studio 18.
Juste un problème pour les emails à envoyer via le démon Database Mail de SQL Server (alertes…), impossible de mettre en route cette fonctionnalité utilisée par beaucoup d’entreprises. Les emails demeurent
dans la file avec des erreurs de timeout. Il n’y avait pas de souci de parefeu ou de paramétrage (serveur SMTP, Port…) car les emails sont envoyés avec succès avec l’exécutable sstmp
.
Impossible de comprendre pourquoi, probablement un bug (SQL Server 2019 est sur une plateforme non supportée ici).
mssql@vps$ ssmtp user@example.com
To: user@example.com
From: user@example.com
Subject: Test
Test from MSSQL
mssql@vps$
Quoi qu’il en soit cette fonctionnalité est supportée et doit fonctionner : DB Mail and Email Alerts with SQL Agent on Linux.
Le profil email de l’agent SQL Server est appliqué avec mssql-conf
.
mssql@vps$ /opt/mssql/bin/mssql-conf set sqlagent.databasemailprofile MSSQLVPS
Conclusion
Une fonction manquante majeure pour l’agent SQL Server sur Linux: la possibilité de contrôler l’agent SQL Server (start/stop/restart) sans
redémarrer le service mssql-server
, il est complètement intégré au moteur contrairement à l’agent SQL Server sur Windows qui est
un service à part.
Dans les environnements utilisant intensivement les jobs SQL Server, c’est un gros problème : si un job est figé quelle qu’en soit la raison, comme l’agent SQL Server n’est pas un service dédié, le moteur SQL Server doit être intégralement redémarré même si on ne souhaite que redémarrer l’agent SQL Server pour débloquer la situation. Cela pourrait peut-être changer dans les prochaines versions.
La fonctionnalité Database mail n’a pas pu être mise en œuvre avec succès mais pour une raison indéterminée (plateforme non supportée…). À suivre…