Pour donner suite à un premier article sur la planification de travaux SQL Server dans Azure, qui utilisait les fonctions Azure, voici à présent une version plus “administrateur système” car à base de PowerShell.
Ceux d’entre vous qui doivent gérer des environnements hétérogènes, ou bien des planifications de travaux complexes faisant intervenir plusieurs systèmes / serveurs ont probablement entendu parler de Microsoft Orchestrator. Il existe bien entendu d’autres produits de ce type sur le marché. L’idée ici, sur Azure, est similaire, certes l’interface graphique glisser / déplacer en moins perfectionnée, il faut l’avouer.
Azure automation peut donc implémenter un workflow base sur du PowerShell. En bon DBA que vous êtes (devriez être), j’espère que vous vous êtes déjà penché sur PowerShell. Cela doit clairement faire partie de votre panoplie de compétences, ne serait ce que pour automatiser le déploiement de SQL Server, sa configuration voire la migration (suivez mon regard vers dbatools.io) ou différents checks de configuration ou santé (dbachecks).
En premier lieu il faut créer un compte de type automation :
Une fois terminé, un écran vue d’ensemble permet de suivre l’activité des différentes tâches.
Je vous conseille en premier lieu de stocker de manière indépendante et sécurisée les crédentials pour accéder à votre base de donnée. Je trouve cela particulièrement judicieux et approprié, cela évite de diffuser un mot de passe administrateur et ainsi déléguer à certains personnes le droit de créer des RunBooks sans pour autant leur fournir toutes les informations d’indentifications. Voyez cela comme un couple credential / proxy dans l’agent SQL Server.
Je n’avais pas trouvé dans l’utilisation des fonctions Azure de fonction équivalente et aussi simple à mettre en œuvre. Il suffit d’aller dans le menu Information d’identification et de cliquer “Ajouter …”.
Un nouvel écran est proposé permettant de saisir un nom d’utilisateur et un mot de passe, ceux là même que vous aurez préalablement ajouté en tant qu’administrateur de votre base de donnée, ou du moins en capacité d’effectuer les tâches de maintenance ou les actions de votre RunBook.
Reste ensuite à créer le RunBook. Dans le menu adéquat, sélectionner Créer un RunBook.
Donnez lui un nom suffisamment explicite, choisissez en suite votre langage de prédilection, PowerShell dans mon cas.
Le RunBook a présent créé, il suffit de cliquer sur Edition.
Et saisir le code Powershell. Notez au passage la syntaxe Get-AutomationPSCredential pour lire les valeurs et ensuite leur utilisation dans le SQLCMD.
$AzureSQLDatabaseName = "AdventureWorks" $AzureSQLServerName = "sqlagent.database.windows.net" $Cred = Get-AutomationPSCredential -Name "MaintenanceUser" $SQLOutput = $(Invoke-Sqlcmd -ServerInstance $AzureSQLServerName ` -Username $Cred.UserName -Password $Cred.GetNetworkCredential().Password ` -Database $AzureSQLDatabaseName ` -Query "exec [dbo].[IndexOptimize] @Databases ='$AzureSQLDatabaseName'" ` -QueryTimeout 65535 -ConnectionTimeout 60 -Verbose) 4>&1 Write-Output $SQLOutput
Si vous êtes impatients, il y a de fortes chances que vous cliquiez sur Test. Malheureusement, vous avez de grandes chance de tomber sur une erreur de type commande non reconnue.
En fait il manque simplement l’ajout d’une dépendance, l’équivalent d’un import module en quelques sortes.
Rendez vous dans le menu Modules, dans lequel on va simplement rechercher sqlserver dans la galerie
Vous sélectionnez et cliquez sur Importer
Wait …. Et une fois terminé, on peut relancer le test.
Celui ci devrait parfaitement se dérouler à présent, sauf s’il subsiste des erreurs de login ou autre.
Lorsque l’on revient sur la vue d’ensemble, il est possible de sélectionner une exécution et d’en voir la sortie :
Reste à présent à planifier ce RunBook :
Rien de plus à faire, le “Job” va s’exécuter automatiquement suivant votre planification.
Happy scheduling
Ping : Planification Azure SQL Databases–Azure Elastic Jobs | Christophe LAPORTE – Consultant SQL Server