Contrôle de Base de données SQL Windows Azure à l'aide de vues de gestion dynamique
Microsoft Base de données SQL Windows 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 Windows Azure.
Base de données SQL Windows 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 Windows Azure, consultez Vues système (Base de données SQL Windows 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 Windows 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 Windows Azure, elles renvoient des informations concernant uniquement votre base de données logique actuelle.
Remarque |
|---|
| 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. 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 dans Base de données SQL Windows 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 Windows Azure) pour extraire des informations sur les connexions établies avec un serveur Base de données SQL 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. 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
Remarque