Exporter (0) Imprimer
Développer tout

Contrôle de Base de données SQL Azure à l'aide de vues de gestion dynamique

Mis à jour: février 2014

Microsoft Base de données SQL Microsoft Azure active un sous-ensemble de vues de gestion dynamique afin de diagnostiquer les problèmes de performances, qui peuvent être dus à des requêtes longues ou bloquées, des goulets d'étranglement de ressources, des plans de requête médiocres, et ainsi de suite. Cette rubrique fournit des informations sur la façon de détecter les problèmes de performances courants à l'aide des vues de gestion dynamique dans Base de données SQL Microsoft Azure.

Base de données SQL Microsoft Azure prend partiellement en charge trois catégories de vues de gestion dynamique :

  • vues de gestion dynamique liées aux bases de données ;

  • vues de gestion dynamique liées à l'exécution ;

  • vues de gestion dynamique liées aux transactions.

Pour obtenir une liste des vues de gestion dynamique intégralement prises en charge dans Base de données SQL Microsoft Azure, consultez Vues système (Base de données SQL Azure). Pour plus d'informations sur les vues de gestion dynamique, consultez Fonctions et vues de gestion dynamique (Transact-SQL) dans la Documentation en ligne de SQL Server.

Autorisations

Dans Base de données SQL Microsoft Azure, l'interrogation d'une vue de gestion dynamique requiert l'autorisation VIEW DATABASE STATE. L'autorisation VIEW DATABASE STATE renvoie des informations sur tous les objets dans la base de données actuelle.

Pour octroyer l'autorisation VIEW DATABASE STATE à un utilisateur de base de données spécifique, exécutez la requête suivante :

GRANT VIEW DATABASE STATE TO database_user;

Dans une instance de SQL Server sur site, les vues de gestion dynamique renvoient des informations sur l'état du serveur. Dans Base de données SQL Microsoft Azure, elles renvoient des informations concernant uniquement votre base de données logique actuelle.

noteRemarque
Lors de l'exécution des vues sys.dm_exec_sessions et sys.dm_exec_requests, si l'utilisateur a l'autorisation VIEW DATABASE STATE sur la base de données, il voit toutes les sessions en cours d'exécution sur la base de données ; sinon, il voit uniquement la session active.

Calcul de taille de base de données

Vous êtes facturé en fonction de l'édition et de la capacité de vos Base de données SQL Azure. Si la taille de votre base de données atteint sa valeur MAXSIZE, vous recevez un code d'erreur 40544. Vous ne pouvez pas insérer ou mettre à jour des données, ni créer des objets (tels que des tables, des procédures stockées, des vues et des fonctions) si vous ne mettez pas à jour la valeur MAXSIZE de votre base de données ou si vous ne supprimez pas des données. Pour plus d'informations, consultez Comptes et facturation de la Base de données SQL Azure. La vue sys.dm_db_partition_stats renvoie des informations sur la page et le nombre de lignes pour chaque partition dans la base de données, qui peuvent servir à calculer la taille de la base de données.

La requête suivante renvoie la taille de votre base de données (en mégaoctets) :

-- Calculates the size of the database. 

SELECT SUM(reserved_page_count)*8.0/1024

FROM sys.dm_db_partition_stats; 

GO

La requête suivante renvoie la taille des différents objets (en mégaoctets) dans votre base de données :

-- Calculates the size of individual database objects. 

SELECT sys.objects.name, SUM(reserved_page_count) * 8.0 / 1024

FROM sys.dm_db_partition_stats, sys.objects 

WHERE sys.dm_db_partition_stats.object_id = sys.objects.object_id 

GROUP BY sys.objects.name; 

GO

Contrôle des connexions

Vous pouvez utiliser la vue sys.dm_exec_connections (Base de données SQL Azure) pour extraire des informations sur les connexions établies avec un serveur Base de données SQL Azure spécifique et obtenir les détails de chaque connexion. De plus, la vue sys.dm_exec_sessions est utile lors de l'extraction d'informations à propos de toutes les connexions utilisateur et tâches internes actives.

La requête suivante extrait des informations sur la connexion actuelle :


-- monitor connections
SELECT
      e.connection_id,
      s.session_id,
      s.login_name,
      s.last_request_end_time,
      s.cpu_time
FROM
      sys.dm_exec_sessions s
      INNER JOIN sys.dm_exec_connections e
      ON s.session_id = e.session_id
GO

Analyse des performances de requêtes

Les requêtes lentes ou longues peuvent consommer beaucoup de ressources système. Cette section montre comment utiliser des vues de gestion dynamique pour détecter quelques problèmes de performances des requêtes courants. Pour plus d'informations, consultez l'article Résolution des problèmes de performances dans SQL Server 2005 sur Microsoft TechNet.

Recherche des N premières requêtes

L'exemple suivant retourne des informations sur les cinq premières requêtes classées d'après le temps processeur moyen. Cet exemple regroupe les requêtes d'après leur hachage de requête, de sorte que les requêtes logiquement équivalentes soient groupées par leur consommation de ressources cumulative.


-- Find top 5queries
SELECT TOP 5 query_stats.query_hash AS "Query Hash", 
    SUM(query_stats.total_worker_time) / SUM(query_stats.execution_count) AS "Avg CPU Time",
    MIN(query_stats.statement_text) AS "Statement Text"
FROM 
    (SELECT QS.*, 
    SUBSTRING(ST.text, (QS.statement_start_offset/2) + 1,
    ((CASE statement_end_offset 
        WHEN -1 THEN DATALENGTH(st.text)
        ELSE QS.statement_end_offset END 
            - QS.statement_start_offset)/2) + 1) AS statement_text
     FROM sys.dm_exec_query_stats AS QS
     CROSS APPLY sys.dm_exec_sql_text(QS.sql_handle) as ST) as query_stats
GROUP BY query_stats.query_hash
ORDER BY 2 DESC;
GO

Contrôle des requêtes bloquées

Les requêtes lentes ou longues peuvent contribuer à une consommation excessive des ressources et être la conséquence de requêtes bloquées. La cause du blocage peut être une conception d'application médiocre, de mauvais plans de requête, un manque d'index utiles, et ainsi de suite. Vous pouvez utiliser la vue sys.dm_tran_locks pour obtenir des informations sur l'activité de verrouillage actuelle dans votre Base de données SQL Azure. Pour obtenir un exemple de code, consultez sys.dm_tran_locks (Transact-SQL) dans la Documentation en ligne de SQL Server.

Contrôle des plans de requêtes

Un plan de requête inefficace peut également augmenter la consommation du processeur. L'exemple suivant utilise la vue sys.dm_exec_query_stats pour déterminer la requête qui utilise le plus de ressources de processeur cumulées.


-- Monitor query plans
SELECT
    highest_cpu_queries.plan_handle,  
    highest_cpu_queries.total_worker_time, 
    q.dbid, 
    q.objectid, 
    q.number, 
    q.encrypted, 
    q.[text] 
FROM 
    (SELECT TOP 50  
        qs.plan_handle,  
        qs.total_worker_time 
     FROM 
        sys.dm_exec_query_stats qs 
     ORDER BY qs.total_worker_time desc) AS highest_cpu_queries 
     CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS q 
ORDER BY highest_cpu_queries.total_worker_time desc

Voir aussi

Ajouts de la communauté

AJOUTER
Microsoft réalise une enquête en ligne pour recueillir votre opinion sur le site Web de MSDN. Si vous choisissez d’y participer, cette enquête en ligne vous sera présentée lorsque vous quitterez le site Web de MSDN.

Si vous souhaitez y participer,
Afficher:
© 2014 Microsoft