Exercice : Vérifier Azure SQL Database

  • 10 minutes

Maintenant que vous avez vu comment Azure SQL apparaît dans SQL Server Management Studio (SSMS), vous pouvez explorer un outil open source appelé Azure Data Studio. Azure Data Studio fournit un éditeur léger et d’autres outils pour interagir avec Azure Data Services, comme SQL Server local, Azure SQL et Azure Database pour PostgreSQL. Commençons par une brève visite guidée.

Se connecter avec Azure Data Studio

  1. Sur votre appareil local, ouvrez Azure Data Studio. Quand vous l’ouvrez pour la première fois, vous êtes d’abord invité à établir une connexion.

    Si vous êtes invité à activer des fonctionnalités en préversion, sélectionnez Oui.

    Screenshot of the opening view of Azure Data Studio.

    Si vous n’avez pas cette fenêtre ou si vous souhaitez à tout moment ajouter une autre connexion, vous pouvez sélectionner le bouton Nouvelle connexion dans la barre Serveurs. Dans l’exemple suivant, vous obtenez également un aperçu de ce à quoi ressemble une connexion SQL Server. Dans cet exercice, vous n’allez pas vous connecter à SQL Server.

    Screenshot of how to create a new connection in Azure Data Studio.

  2. Connectez-vous à votre serveur logique Azure SQL Database. Complétez les détails de Connecter ion avec les valeurs suivantes, puis sélectionnez Connecter.

    Paramètre Valeur
    Type de connexion Microsoft SQL Server
    Serveur Entrez le nom de votre serveur logique
    Type d’authentification Connexion SQL
    Nom d’utilisateur cloudadmin
    Mot de passe Entrez le mot de passe pour le compte cloudadmin
    Mémoriser le mot de passe Sélectionné
    Base de données AdventureWorks
    Groupe de serveurs Quitter en tant que <Default>
    Nom (facultatif) Laisser vide

  3. Sous l’onglet Connexions, sous Serveurs, vous devez maintenant voir votre connexion Azure SQL Database. La connexion SQL Server de l’image suivante est montrée seulement à des fins de comparaison.

    Screenshot that compares SQL Server and SQL Database in Azure Data Studio.

  4. Azure Data Studio et SSMS ont un processus d’exécution de requêtes similaire. Cliquez avec le bouton droit sur le nom d’une base de données ou d’un serveur, puis sélectionnez Nouvelle requête.

  5. Pour Azure SQL Database, comme vous n’obtenez pas un « serveur » complet, USE [Nom_base_de_données] n’est pas pris en charge pour changer de contexte de base de données. Vous devez soit changer la connexion pour vous connecter spécifiquement à la base de données sur laquelle vous souhaitez exécuter une requête, soit utiliser la liste déroulante. Passez au contexte de votre base de données AdventureWorks en sélectionnant l’option à côté de master et exécutez SELECT @@VERSION.

    Screenshot of querying in Azure Data Studio.

    Plus loin dans cet exercice, vous voyez en détail pourquoi le résultat est différent de ce que vous voyez dans SQL Server.

Configurer un accès facile aux fichiers avec Azure Data Studio

Maintenant que vous êtes connecté, vous pouvez créer un moyen simple d’accéder aux scripts et aux notebook Jupyter. Un notebook Jupyter est un moyen d’intégrer du code exécutable à du texte. Si vous n’êtes pas familiarisé avec les notebooks Jupyter, vous le serez bientôt.

  1. Dans Azure Data Studio, sélectionnez Fichiers>Ouvrir le dossier.

    Screenshot of opening a folder in Azure Data Studio.

  2. Accédez à l’emplacement où vous avez extrait le fichier zip des ressources pour cet exercice. Si vous avez suivi les prérequis, le chemin d’accès doit être similaire à C :\Users\<machine-username>\mslearn-azure-sql-fundamentals. Quand vous y êtes, sélectionnez Sélectionner un dossier. Si vous y êtes invité, sélectionnez Oui, je fais confiance aux auteurs.

  3. Ensuite, sélectionnez l’icône Explorer dans la barre des tâches à gauche pour parcourir les fichiers du module. Ce dossier contient toutes les ressources nécessaires pour le parcours d’apprentissage sur les concepts de base d’Azure SQL : vous ne devez le télécharger et configurer cette information qu’une seule fois !

    Dans les exercices du module et du parcours d’apprentissage, il êtes demandé à différents points d’ouvrir un fichier notebook un fichier qui a l’extension de nom de fichier : .ipynb. Vous pouvez accéder directement au notebook à partir d’ici. Vous pouvez aussi y accéder à partir de l’onglet avec l’icône Notebook.

Vérifier le déploiement

Après avoir déployé une instance de SQL, vous exécutez généralement des requêtes pour vérifier votre déploiement. Dans Azure SQL, certaines de ces requêtes diffèrent de celles de SQL Server. Dans cette étape, vous découvrez les différences avec SQL Server et ce qui est nouveau.

Il existe deux options pour effectuer cet exercice :

  • T-SQL dans SSMS
  • Notebooks SQL dans Azure Data Studio

Les deux exercices contiennent les mêmes commandes et le même contenu : vous pouvez ainsi choisir l’option que vous préférez.

Option 1 : T-SQL dans SSMS

Dans cette option, vous parcourez certaines requêtes courantes sur les fonctions système, les vues de gestion dynamique (DMV) et les vues de catalogue que vous pouvez utiliser après le déploiement dans SSMS. Voir celles qui fonctionnent comme dans SQL Server, celles qui ne fonctionnent pas et celles qui sont nouvelles dans Azure SQL.

  1. Si ce n’est pas déjà fait, connectez-vous à votre serveur logique Azure SQL Database dans SSMS.

  2. Cliquez avec le bouton droit sur la base de données AdventureWorks, puis sélectionnez Nouvelle requête.

  3. Vérifiez la version que vous avez déployée en exécutant la fonction système bien connue @@VERSION.

    SELECT @@VERSION

    Screenshot of the result of the SELECT @@VERSION function.

    Le résultat est un peu différent de SQL Server. Vous pouvez savoir que ce serveur est Azure SQL, qui n’a pas de versions. Azure SQL Database inclut les modifications les plus récentes conformes à la dernière version de SQL Server. Cependant, l’utilisation de la fonction système @@VERSION est une méthode courante pour vérifier que vous pouvez « interroger » SQL Server.

  4. Déterminez le type spécifique du déploiement Azure SQL, en fonction du nombre retourné :

    • 1 = Personal ou Desktop Engine
    • 2 = Standard
    • 3 = Enterprise
    • 4 = Express
    • 5 = SQL Database
    • 6 = SQL Data Warehouse
    • 8 = SQL Managed Instance

    Exécutez la commande T-SQL suivante pour voir si vous obtenez le résultat attendu.

    SELECT SERVERPROPERTY('EngineEdition');

    Screenshot of the results for the Azure SQL deployment.

    Le résultat est 5, ce qui est logique, car vous avez déployé Azure SQL Database, et non pas SQL Managed Instance ou SQL Server Enterprise. Il n’existe aucun numéro spécial pour SQL Server dans Machines virtuelles Azure. Le nombre correspond à l’édition que vous avez installée sur la machine virtuelle. Personal ou Desktop Engine est une édition antérieure qui n’est plus utilisée avec SQL Server.

  5. Examiner les affichages catalogue sys.databases et sys.objects. En règle générale, vous examinez ces vues pour vérifier l’installation et l’état des bases de données système ainsi que les objets système de votre base de données.

    SELECT * FROM sys.databases;
SELECT * FROM sys.objects;

    Screenshot of the results for sys.databases and sys.objects.

    Dans le premier jeu de résultats, les bases de données système msdb, tempdb et model ne sont pas listées. Seuls master et votre base de données utilisateur sont listées. La base de données Master pour un serveur de base de données pour Azure SQL Database n’est pas la même que la base de données Master physique installée avec SQL Server. Dans Azure SQL Managed Instance, vous voyez l’ensemble normal des bases de données système comme avec n’importe quel instance de SQL Server.

    Cependant, sys.objects ressemble à une instance normale de SQL Server. Ce fait est vrai pour les tables système, les tables internes et les objets utilisateur de l’exemple de base de données AdventureWorksLT.

  6. Vérifiez que tous les planificateurs sont en ligne et que nous détectons les processeurs disponibles attendus, étant donné que vous avez déployé avec un modèle 2 vCores.

    SELECT * FROM sys.dm_os_schedulers where STATUS = 'VISIBLE ONLINE';

    Screenshot of the results for sys.dm_os_schedulers.

    Deux planificateurs VISIBLE ONLINE sont ceux que vous attendez quand 2 vCores sont disponibles pour l’instance de SQL Server où votre base de données SQL est déployée.

  7. Pour un déploiement SQL Server, vous pouvez normalement examiner des vues de gestion dynamiques comme sys.dm_process_memory pour voir les limites en termes de processeur, de mémoire et de Workers. Cette vue de gestion dynamique n’est pas prise en charge avec Azure SQL Database, car l’utilisateur n’expose pas et ne contrôle pas les détails de l’hôte qui prend en charge la base de données. Vous pouvez utiliser la vue de gestion dynamique sys.dm_user_db_resource_governance pour passer en revue les capacités et les limites de votre base de données SQL déployée. Vous pouvez également utiliser sys.dm_instance_resource_governance dans Azure SQL Managed Instance.

    Exécutez la requête suivante et examinez ses résultats. Comparez-les résultats à votre niveau tarifaire et aux limites documentées pour votre niveau déployé. slo_name est l’objectif de niveau de service (SLO) qui indique l’option de déploiement, le niveau de service, le matériel et la quantité de calcul. En outre, comme Azure SQL Database utilise des objets de tâche Windows pour définir d’autres limites de ressources telles que la mémoire, vous pouvez utiliser la vue de gestion dynamique sys.dm_os_job_object afin d’afficher les ressources disponibles pour le déploiement.

    SELECT * FROM sys.dm_user_db_resource_governance;

    Screenshot of the results showing resource governance limits.

  8. Une technique courante pour regarder un déploiement SQL Server consiste à examiner une liste de demandes actives. Tout comme SQL Server, vous pouvez utiliser sys.dm_exec_requests pour afficher les requêtes SQL en cours d’exécution.

    SELECT * FROM sys.dm_exec_requests;

    Screenshot of the results showing dm_exec_requests.

    sys.dm_exec_requests ne s’utilise pas de la même façon dans Azure SQL Database et dans SQL Server ou SQL Managed Instance. Cette vue de gestion dynamique montre seulement les demandes actives liées à votre base de données, y compris les tâches d’arrière-plan ou les tâches d’arrière-plan qui n’ont pas de contexte de base de données affichées en tant que master. Ce comportement est dû à la nature d’un déploiement Azure SQL Database, où chaque base de données est déployée sur sa propre instance de SQL Server.

Option 2 : Notebooks SQL dans Azure Data Studio

Pour cette option, vous utilisez le notebook VerifyDeployment.ipynb. Il se trouve sous 02-DeployAndConfigure\verifydeployment\VerifyDeployment.ipynb dans le référentiel GitHub ou le fichier zip que vous avez téléchargé précédemment. Accédez à ce fichier dans Azure Data Studio pour effectuer cette partie de l’exercice, puis revenez ici. Dans le même dossier, vous trouvez également des notebooks supplémentaires contenant les résultats des mêmes requêtes sur Azure SQL Managed Instance et SQL Server 2019.

Si vous ne parvenez pas à effectuer l’exercice pour une raison quelconque, vous pouvez passer en revue les résultats dans le fichier du notebook correspondant sur GitHub.