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

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.

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.

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

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

Plus loin dans cet exercice, vous verrez en détail pourquoi le résultat est différent de celui que vous obtenez 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.

Dans Azure Data Studio, sélectionnez Fichiers>Ouvrir le dossier.
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.
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 ces informations 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. Lors de cette étape, vous allez voir ce qui a changé dans SQL Server, comment elles ont changé, et quelles sont les nouveautés.

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 allez parcourir certaines requêtes courantes sur les fonctions système, les vues de gestion dynamique (DMV) et les affichages catalogue que vous pouvez utiliser après le déploiement dans SSMS. Vous allez découvrir celles qui fonctionnent comme dans SQL Server, celles qui ne fonctionnent pas, et celles qui sont nouvelles dans Azure SQL.

Si ce n’est pas déjà fait, connectez-vous à votre serveur logique Azure SQL Database dans SSMS.
Cliquez avec le bouton droit sur la base de données AdventureWorks, puis sélectionnez Nouvelle requête.
Vérifiez la version que vous avez déployée en exécutant la fonction système bien connue @@VERSION.
```
SELECT @@VERSION
```
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.
Déterminez le type spécifique du déploiement Azure SQL, en fonction du nombre retourné :
- 1 : Personal ou Desktop Engine
- 2 : Standard
- 3 : Entreprise
- 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');
```
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 Entreprise. 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.
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;
```
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 d’un serveur logique Azure SQL n’est pas la même que la base de données physique master 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.
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';
```
Deux planificateurs VISIBLE ONLINE sont ce à quoi vous vous attendez quand deux vCores sont disponibles pour l’instance de SQL Server où votre base de données SQL est déployée.
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;
```
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;
```
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 requêtes 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é comme master. Ce comportement est dû à la nature d’un déploiement Azure SQL Database.

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 trouverez également des notebooks supplémentaires contenant les résultats des mêmes requêtes sur Azure SQL Managed Instance et SQL Server 2019.