Sorte de. Vérifiez cette requête :
SELECT total_worker_time/execution_count AS AvgCPU
, total_worker_time AS TotalCPU
, total_elapsed_time/execution_count AS AvgDuration
, total_elapsed_time AS TotalDuration
, (total_logical_reads+total_physical_reads)/execution_count AS AvgReads
, (total_logical_reads+total_physical_reads) AS TotalReads
, execution_count
, SUBSTRING(st.TEXT, (qs.statement_start_offset/2)+1
, ((CASE qs.statement_end_offset WHEN -1 THEN datalength(st.TEXT)
ELSE qs.statement_end_offset
END - qs.statement_start_offset)/2) + 1) AS txt
, query_plan
FROM sys.dm_exec_query_stats AS qs
cross apply sys.dm_exec_sql_text(qs.sql_handle) AS st
cross apply sys.dm_exec_query_plan (qs.plan_handle) AS qp
ORDER BY 1 DESC
Cela vous permettra d'obtenir les requêtes dans le cache du plan dans l'ordre de la quantité de CPU qu'elles ont utilisé. Vous pouvez l'exécuter périodiquement, comme dans une tâche SQL Agent, et insérer les résultats dans une table pour vous assurer que les données persistent au-delà des redémarrages.
Lorsque vous lirez les résultats, vous comprendrez probablement pourquoi nous ne pouvons pas corréler directement ces données à une base de données individuelle. Tout d'abord, une seule requête peut également masquer son véritable parent de base de données en faisant des astuces comme celle-ci :
USE msdb
DECLARE @StringToExecute VARCHAR(1000)
SET @StringToExecute = 'SELECT * FROM AdventureWorks.dbo.ErrorLog'
EXEC @StringToExecute
La requête serait exécutée dans MSDB, mais elle interrogerait les résultats d'AdventureWorks. Où devrions-nous attribuer la consommation CPU ?
Cela s'aggrave lorsque vous :
- Joindre plusieurs bases de données
- Exécutez une transaction dans plusieurs bases de données et l'effort de verrouillage s'étend sur plusieurs bases de données
- Exécutez les tâches de l'Agent SQL dans MSDB qui "fonctionnent" dans MSDB, mais sauvegardez les bases de données individuelles
Et ça continue, encore et encore. C'est pourquoi il est logique d'ajuster les performances au niveau de la requête plutôt qu'au niveau de la base de données.
Dans SQL Server 2008R2, Microsoft a introduit des fonctionnalités de gestion des performances et de gestion des applications qui nous permettront de regrouper une seule base de données dans un pack DAC distribuable et déployable, et ce sont des fonctionnalités prometteuses pour faciliter la gestion des performances des bases de données individuelles et de leurs applications. Cependant, il ne fait toujours pas ce que vous recherchez.
Pour plus d'informations, consultez le Référentiel T-SQL sur le wiki SQL Server de Toad World (anciennement sur SQLServerPedia) .
Mise à jour le 29/01 pour inclure les nombres totaux au lieu de simples moyennes.
