2

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

twitterlinkedinmail

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 :

twitterlinkedinmail

Capdata team

2 commentaires

  1. 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.

  2. Thanks for the info, I didn’t have the opportunity to test it again, I will have a look soon !

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.