Algo así como. Mira esta consulta:
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
Esto le dará las consultas en el caché del plan en orden de cuánta CPU han usado. Puede ejecutar esto periódicamente, como en un trabajo del Agente SQL, e insertar los resultados en una tabla para asegurarse de que los datos persistan más allá de los reinicios.
Cuando lea los resultados, probablemente se dará cuenta de por qué no podemos correlacionar esos datos directamente con una base de datos individual. En primer lugar, una sola consulta también puede ocultar su verdadero padre de base de datos haciendo trucos como este:
USE msdb
DECLARE @StringToExecute VARCHAR(1000)
SET @StringToExecute = 'SELECT * FROM AdventureWorks.dbo.ErrorLog'
EXEC @StringToExecute
La consulta se ejecutaría en MSDB, pero sondearía los resultados de AdventureWorks. ¿Dónde debemos asignar el consumo de CPU?
Empeora cuando:
- Únete entre varias bases de datos
- Ejecute una transacción en varias bases de datos y el esfuerzo de bloqueo abarcará varias bases de datos
- Ejecutar trabajos del Agente SQL en MSDB que "funcionan" en MSDB, pero respaldar bases de datos individuales
Lo sigue y sigue. Por eso tiene sentido ajustar el rendimiento a nivel de consulta en lugar de a nivel de base de datos.
En SQL Server 2008R2, Microsoft introdujo funciones de gestión del rendimiento y gestión de aplicaciones que nos permitirán empaquetar una sola base de datos en un paquete DAC distribuible e implementable, y son funciones prometedoras para facilitar la gestión del rendimiento de las bases de datos individuales y sus aplicaciones. Sin embargo, todavía no hace lo que estás buscando.
Para obtener más información, consulte Repositorio T-SQL en el wiki de SQL Server de Toad World (anteriormente en SQLServerPedia) .
Actualizado el 29/1 para incluir números totales en lugar de solo promedios.
