Exercice : Vérifier Azure SQL Database

Effectué

Maintenant que vous avez vu comment Azure SQL apparaît dans SQL Server Management Studio (SSMS), vous pouvez vérifier le déploiement.

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.

Dans cet exercice, vous parcourez certaines requêtes courantes sur les fonctions système, les vues de gestion dynamique (DMV) et les vues 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.

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
   

   

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

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;
   

   

   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 master base de données d’un serveur logique 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.

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';
   

   

   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.

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;
   

   

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;
   

   

   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.