Exercice : Configurer Azure SQL Database

  • 10 minutes

Vous avez maintenant vu le portail Azure, SQL Server Management Studio (SSMS) et les notebooks SQL dans Azure Data Studio. D’autres outils sont à votre disposition pour la gestion d’Azure SQL. Deux des outils les plus répandus sont Azure CLI et Azure PowerShell. Ils sont similaires d’un point de vue fonctionnel. Cette activité se concentre sur Azure CLI.

Pour effectuer cette activité, vous pouvez utiliser un notebook PowerShell, qui est le même concept qu’un notebook SQL, sauf que le langage de codage est PowerShell. Vous pouvez utiliser des notebooks PowerShell pour tirer parti d’Azure CLI ou d’Azure PowerShell. Cet article se concentre sur les commandes Azure CLI. Pour ces deux outils, vous pouvez aussi utiliser Azure Cloud Shell, qui est un environnement de shell interactif que vous pouvez utiliser via votre navigateur dans le portail Azure.

Dans cet exercice, utilisez Cloud Shell. Il inclut déjà les modules Azure CLI et Azure PowerShell.

Connexion avec Azure Cloud Shell et Azure CLI

Dans l’exemple qui suit, explorez les effets de la latence liés à l’utilisation de différentes stratégies de connexion dans Azure SQL.

Exécutez toutes les commandes avec Cloud Shell. Vous pouvez les copier facilement, puis sélectionner Maj+Inser pour les coller dans le terminal.

Remarque

Dans PowerShell à l’aide d’Azure Cloud Shell, vous pouvez utiliser le module PowerShell Az ou Azure CLI. Dans cette activité, explorez Azure CLI, mais des commandes similaires sont disponibles pour le module PowerShell Az.

  1. Accédez à shell.azure.com, puis connectez-vous à votre compte Azure si vous y êtes invité.

  2. Configurez un groupe de ressources par défaut et un serveur logique Azure SQL Database, de façon à ne pas devoir les spécifier avec chaque commande az. Exécutez les commandes suivantes pour définir des variables. Remplacez <resource-group> et <your-server> par les valeurs que vous avez utilisées lorsque vous avez créé votre instance SQL dans l’exercice précédent.

    resourceGroup="<resource-group>"
logical_server="<your-server>"
databaseName="AdventureWorks"

  3. Définissez les valeurs par défaut dans Cloud Shell pour spécifier votre groupe de ressources et votre serveur logique Azure SQL Database par défaut :

    az configure --defaults group=$resourceGroup sql-server=$logical_server

  4. Exécutez la commande suivante pour vérifier que les valeurs par défaut ont été définies :

    az configure --list-defaults

  5. Exécutez la commande suivante pour afficher toutes les bases de données du serveur logique Azure SQL Database :

    az sql db list

  6. La liste des bases de données représente une grande quantité d’informations. Exécutez la commande suivante si vous voulez simplement voir les spécificités de la base de données AdventureWorks :

    az sql db show --name $databaseName

  7. Exécutez la commande suivante pour déterminer la taille et l’utilisation de la base de données :

    az sql db list-usages --name $databaseName

Ces exemples utilisent les commandes az sql db. Il existe également des commandes relatives au serveur logique Azure SQL Database. Ils se trouvent sous az sql server.

Il existe des commandes similaires pour az sql mi et az sql midb. Il s’agit de commandes pour les bases de données dans une instance managée, parfois appelées bases de données managées.

Pour obtenir des explications détaillées sur toutes les commandes disponibles, reportez-vous à la documentation d’Azure CLI.

Gérer des stratégies de connexion avec Azure CLI

Vous pouvez notamment utiliser les commandes Azure PowerShell ou Azure CLI pour mettre à jour la stratégie de connexion. Cette mise à jour est un exemple de la façon dont vous pouvez gérer Azure SQL avec un outil de type Azure CLI. Dans cet exemple, vous examinez Azure SQL Database et ses commandes pour gérer les stratégies de connexion. L’implémentation est similaire dans Azure SQL Managed Instance.

  1. Voyons quelle est la stratégie actuelle en utilisant Azure CLI.

    az sql server conn-policy show

    Les résultats vous indiquent que le type de connexion est Default.

  2. Définissez la stratégie de connexion sur Proxy et déterminez la durée des allers-retours.

    # update policy
az sql server conn-policy update --connection-type Proxy
# confirm update
az sql server conn-policy show

  3. Pour tester la durée aller-retour, connectez-vous en utilisant SSMS. Sur votre appareil, ouvrez SSMS et connectez-vous à votre base de données. Cliquez avec le bouton droit sur la base de données et sélectionnez Nouvelle requête. Créez une requête avec le texte suivant, puis sélectionnez Requête>Inclure les statistiques du client. Dans les résultats, Délai d’attente des réponses du serveur est le meilleur indicateur de la latence réseau. Vous pouvez exécuter cette requête plusieurs fois pour obtenir une bonne moyenne.

    -- Proxy
SELECT * FROM SalesLT.Product
GO 10

    Après 10 essais, un temps d’attente moyen des réponses du serveur devrait être d’environ 46.6000. Vos résultats peuvent varier en fonction de votre connexion Internet. Notez l’heure à laquelle vous faites ces observations.

  4. Que se passe-t-il si nous voulons tout rendre Redirect pour essayer d’atteindre une latence réduite ?

    Pour tout ce qui se trouve en dehors d’Azure, vous devez autoriser les communications entrantes et sortantes sur les ports de la plage 11000-11999. L’ouverture de ces ports est nécessaire pour la stratégie de connexion Redirect.

    Notes

    C’est probablement déjà configuré sur votre appareil local. Si vous rencontrez des erreurs lors des étapes suivantes, il peut être nécessaire d’activer les ports mentionnés précédemment. Pour plus d’informations, consultez Ports au-delà de 1433 pour ADO.NET 4.5.

    Mettez à jour la stratégie de connexion et vérifiez cette mise à jour avec les deux commandes suivantes.

    # update policy
az sql server conn-policy update --connection-type Redirect
# confirm update
az sql server conn-policy show

  5. Pour tester la latence réseau de la stratégie Redirect, connectez-vous à SSMS sur votre appareil local. Créez une requête avec le texte suivant, puis choisissez d’Inclure les statistiques du client dans vos résultats. Comparez le Délai d’attente des réponses du serveur avec votre requête pour Proxy.

    -- Redirect
SELECT * FROM SalesLT.Product
GO 10

    Après 10 essais, le temps d’attente moyen des réponses du serveur peut être d’environ 25.8000, soit près de la moitié de celui de la stratégie de connexion par proxy. Les durées exactes varient en fonction de votre connexion. La durée devrait être considérablement réduite, comparé à votre test de proxy précédent.

  6. Rétablissez la stratégie par défaut pour l’exercice suivant à l’aide des commandes suivantes :

    # update policy
az sql server conn-policy update --connection-type Default
# confirm update
az sql server conn-policy show

La redirection est plus rapide, car après la connexion initiale, vous pouvez contourner la passerelle et accéder directement à la base de données. Ce contournement signifie moins de tronçons et donc une latence moindre. Une latence moindre contribue à éviter les goulots d’étranglement, ce qui est particulièrement important pour les applications très interactives. Dans le module sur les performances, vous apprenez plus en détail comment améliorer et optimiser les performances.