SQL Server Managed Instance dans Azure et le SQL Agent : pareil que du On-Prem ?

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 (Vincent Delabre) [AzureSQL Server]
• Un trigger fait-il parti d’une transaction ? (Benjamin VESAN) [GénéralMySQLOracleSQL ServerSybase]
• Déterminer la fréquence horaire d’exécution d’une procédure stockée sous SQL Server (Vincent Delabre) [SQL Server]
• Production SQL Server : Sauvegardes (Benjamin VESAN) [SQL Server]
• Retrouver une transaction en échec (David Baffaleuf) [SQL Server]