Contrairement à l’offre PaaS SQL Server initiale de Azure, qui ne dispose pas de l’Agent SQL Server, la nouvelle offre SQL Managed Instance promet de résoudre ce problème.
A nous les joies des jobs de maintenance des index et des stats “fait maison” , des procédures d’intégration des données métier , etc…
Souvent, quand je réalise des tests nécessitant de simuler une petite activité sur une base de test, par exemple pour faire bouger un peu mon log transactionnel, j’utilise la technique suivante :
1 – Je créé une table avec 2 colonnes : un ID de type integer, avec identity, et une colonne avec un timestamp.
CREATE TABLE [dbo].[t1]( [id] [int] IDENTITY(1,1) NOT NULL, [ma_date] [datetime] NOT NULL )
2 – Je créé un job qui va régulièrement ajouter une ligne avec la date du moment
insert into t1 values (getdate());
Pour sa planification, j’utilise habituellement un intervalle assez cours, de l’ordre de quelques secondes.
Cela permet ainsi de valider les temps de bascule sur des solutions de PCA/PRA, des réplications etc…
Sauf que dans le cadre d’une Managed Instance, on va mystérieusement se retrouver avec l’erreur ci-dessous :
Msg 41914, Level 16, State 5, Procedure msdb.dbo.sp_update_schedule, Line 48 [Batch Start Line 4]
SQL Server Agent feature Schedule job ONIDLE is not supported in SQL Database Managed Instance. Review the documentation for supported options.
Eh oui ! L’utilisation d’une planification récurrente dans l’Agent SQL Server (en dessous de la journée, en fait) se traduit comme un job avec la propriété “on idle CPU” : c’est à dire qui ne s’exécute que si la capacité CPU n’est pas saturée.
On ne peut donc pas planifier un job SQL avec une fréquence inférieure à la journée !
On se consolera en faisant une planification quotidienne (qui marche, heureusement), et une boucle while / waitfor delay de 5 secondes :
while convert(time, getdate()) < '23:59:55' BEGIN INSERT INTO t1 VALUES (getdate()) waitfor delay '00:00:05' END
En tout cas, penser que SQL Server Managed Instance est strictement identique à une instance SQL On-Premise est une erreur. Plus d’info : https://docs.microsoft.com/fr-fr/azure/sql-database/sql-database-managed-instance-transact-sql-information
Continuez votre lecture sur le blog :
- Elastic Job Agent : l’Agent SQL Server pour le PaaS Azure (Capdata team) [AzureSQL Server]
- Un trigger fait-il parti d’une transaction ? (Benjamin VESAN) [GénéralMySQLOracleSQL ServerSybase]
- Retrouver une transaction en échec (David Baffaleuf) [SQL ServerVintage]
- Déterminer la fréquence horaire d’exécution d’une procédure stockée sous SQL Server (Capdata team) [SQL Server]
- Production SQL Server : Sauvegardes (Benjamin VESAN) [SQL Server]
This was bug in version 17.9.1 of SSMS and has been fixed apparently in 18.1 (definitely works in 18.12.1). Just letting you know because a) your blog post helped narrow down the issue and b) so you can update your jobs to a more simpler approach.
Thanks for the info, I didn’t have the opportunity to test it again, I will have a look soon !