Planification Azure SQL Databases–Azure functions

Il y a un peu plus de 20 ans je découvrais SQL Server. Déjà, avec SQL Server 6.5 il existait des assistant dans Management Studio qui facilitaient la vie du DBA.

Tout d’abord, SQL trace ! Certains d’entre vous font l’association avec l’actuel profiler. C’est bien le cas, il s’agissait bien de l’utilitaire graphique permettant de visualiser l’activité du serveur ….

Hydra, SQL Server 6.5, a aussi vu l’apparition d’un assistant qui encore le bonheur des administrateurs : le Database maintenance Plan Wizard. Oui, les plans de maintenance ! Pas tout à fait sous leur forme actuelle. Pas d’agent SQL, mais son ancêtre SQLExecutive.

Il y a donc des tâches qui incombent encore DBA. La sauvegarde, le test d’intégrité, la gestion des index et statistiques d’index.

Et puis Azure SQL Databases vient bousculer les habitudes. Certains s’imaginent que leur métier de DBA va disparaitre. Non, il va seulement se transformer. Probablement en administrateur de données plutôt qu’en administrateur de bases de données.

Lorsque j’interviens sur ces bases « managées », il est fréquent qu’aucune maintenance ne soit effectuée. Certes les sauvegardes sont gérées par l’hébergeur, Microsoft, mais la réindexation, voire les tests d’intégrité restent à la charge du client, vous … Et qui dit pas de réindexation ou de mise à jour de statistique d’index dit problèmes de performance à venir.

Quid des performances dans Azure ? Certes il faut compter avec la latence réseau que l’on ne rencontre pas quand l’applicatif et la base de données sont hébergés dans le même datacenter, proche des utilisateurs. Mais la performance d’une requête est aussi très largement guidée par la présence d’index et par la fraicheur des statistiques d’index. N’hésitez pas à planifier des Update Stats fréquemment.

SQL Server sur Azure, ce n’est pas du SaaS, mais « seulement » du PaaS. Il reste donc des points que vous devez gérer. Comme la maintenance des index !!!

clip_image002

Historiquement les travaux sont planifiés au travers de l’agent SQL Server. Le problème étant qu’il n’y a pas d’agent SQL sur Azure !

Il faut donc trouver des solutions de contournement pour planifier la gestion des index :

  • Créer un plan de maintenance sur une instance SQL disposant d’un agent et modifier le serveur cible en désignant la base SQL Azure
  • Utiliser Azure automation
  • Créer une Azure fonction

Afin de rester cohérant avec la philosophie PaaS, je vais présenter en priorité les solutions serverless. Au passage, si vous êtes en phase de conception d’une nouvelle application, je vous encourage fortement à vous intéresser à ce type d’architecture, plutôt basée micro services (par opposition aux applications monolithiques que l’on rencontrait par le passé).

Dans ce billet, nous allons aborder les fonctions Azure, de manière simple, dans le but d’exécuter du code dans une base de données à intervalle planifié, un job en quelques sortes Smile. Et quoi de plus logique que de planifier la réindexation et la mise à jour des statitiques.

Pour cela, j’ai créé un environnement de test depuis le portail Azure. Un serveur de bases de données, en France puisque la région est à présent disponible, et une base de données.

Un point important à ne pas oublier au sujet de Azure SQL Databases : il n’est pas possible d’exécuter du code Cross-Database. Autrement dit, on ne peut pas généraliser la procédure à l’ensable des bases du « serveur ».

A titre personnel, je préconise et utilise les scripts de Ola Hallengren comme scripts de maintenance. Que ce soit pour les sauvegardes, la gestion des index ou des tests d’intégrité.

Il faudra donc déployer les scripts, en fait les fichiers CommandLog, CommandExecute et IndexOptimize, dans chaque base.

  clip_image003

La tarification et les performances sont liés à la base, il parait logique que les ressources consommées pour la réindexation soient aussi à la charge de la base et non pas liées à une base système ou utilisateur prévue à cet effet.

Etant donné que les bases partiellement contenues sont disponibles dans Azure, nous allons créer un User with Password:

CREATE USER [Maintenance.User] 
WITH PASSWORD = '<str0ng_p@ssw0rd>'
GO
EXEC sp_addrolemember N'db_owner', 
                      N'Maintenance.User'
GO

Il reste à présent à configurer la fonction Azure pour appeler la procédure stockée.

Depuis le portail Azure, il suffit de rechercher le mot clé « Function »

image

Et de démarrer la configuration

clip_image006

Une fois terminé l’app service est présent.

image

Il faut maintenant configurer la fonction en y ajoutant le code que l’on souhaite exécuter, comme nous y invite l’interface graphique.

clip_image010

L’assistant nous propose différentes options pour coder la fonction. Il est possible d’utiliser Visual Studio ou Visual Studio Code, ou bien de passer par l’éditeur de Azure.

clip_image012

S’agissant d’une fonction, il est possible d’opter pour un déclanchement au travers d’un appel HTTP ou bien d’utiliser un déclencheur basé sur un minuteur. C’est cette dernière option que nous choisirons.

clip_image014

Et d’utiliser quelques lignes de C# :

#r "System.Configuration"
#r "System.Data"

using System;
using System.Text;
using System.Configuration;
using System.Data;
using System.Data.SqlClient;
using System.Threading.Tasks;

public static void Run(TimerInfo myTimer, TraceWriter log)
{
    log.Info($"C# Timer trigger function executed at: {DateTime.Now}");
    var str = "Server=tcp:sqlagent.database.windows.net,1433;Initial Catalog=AdventureWorks;Persist Security Info=False;User ID=Maintenance.User;Password=;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;";
    using (SqlConnection conn = new SqlConnection(str))
    {                    
        StringBuilder sb = new StringBuilder();                    
        sb.Append("exec [dbo].[IndexOptimize] @Databases ='AdventureWorks'");
        String sql = sb.ToString();                    
        using (SqlCommand command = new SqlCommand(sql, conn))
        {
            command.Connection.Open();
            command.ExecuteNonQuery();
        }                                   
    }
}

clip_image016

Il est possible de tester la fonction au travers du bouton exécuter.

clip_image018

Une fois le test effectué, vient l’étape de la planificiation.

image

Le format utiliser est similaire au Crontab que connaissent les Linuxiens. Heureusement pour nous, une aide précieuse est disponible dans l’interface, ou bien une recherche dans votre moteur favoris vous en dira plus.

Il est possible de désactiver la planification au travers d’un switch spécifique :

image

La fonction, elle, peut être stoppée, comme si l’on stoppait le site Web.

Deux principaux inconvénients quant à l’utilisation des fonctions :

  • Une durée d’exécution limitée même s’il est possible de modifier les 5 minutes par défaut (un peu juste pour de la réindexation sur de grosses bases)
  • Par défaut, pas de possibilité de stocker les crédentials de la chaine de connexion et donc de devoir avoir les informations en clair.

Happy scheduling

Publicités

A propos Christophe

Consultant SQL Server Formateur certifié Microsoft MVP SQL Server MCM SQL Server 2008
Cet article, publié dans Azure Function, SQL Azure, est tagué . Ajoutez ce permalien à vos favoris.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s