På en måde. Tjek denne forespørgsel ud:
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
Dette vil give dig forespørgslerne i planens cache i rækkefølge af, hvor meget CPU de har brugt op. Du kan køre dette med jævne mellemrum, som i et SQL Agent-job, og indsætte resultaterne i en tabel for at sikre, at dataene bliver ved efter genstart.
Når du læser resultaterne, vil du sandsynligvis indse, hvorfor vi ikke kan korrelere disse data direkte tilbage til en individuel database. For det første kan en enkelt forespørgsel også skjule sin sande databaseforælder ved at udføre tricks som dette:
USE msdb
DECLARE @StringToExecute VARCHAR(1000)
SET @StringToExecute = 'SELECT * FROM AdventureWorks.dbo.ErrorLog'
EXEC @StringToExecute
Forespørgslen ville blive udført i MSDB, men den ville polle resultater fra AdventureWorks. Hvor skal vi tildele CPU-forbruget?
Det bliver værre, når du:
- Slå sammen mellem flere databaser
- Kør en transaktion i flere databaser, og låseindsatsen spænder over flere databaser
- Kør SQL Agent-job i MSDB, der "virker" i MSDB, men sikkerhedskopier individuelle databaser
Det bliver ved og ved. Det er derfor, det giver mening at tune ydeevnen på forespørgselsniveauet i stedet for databaseniveauet.
I SQL Server 2008R2 introducerede Microsoft præstationsstyring og app-administrationsfunktioner, der vil lade os pakke en enkelt database i en distribuerbar og deployerbar DAC-pakke, og de lover funktioner, der gør det nemmere at administrere ydeevnen for individuelle databaser og deres applikationer. Det gør dog stadig ikke, hvad du leder efter.
For flere af dem, tjek T-SQL-lager på Toad Worlds SQL Server-wiki (tidligere hos SQLServerPedia) .
Opdateret den 29.1. til at inkludere samlede tal i stedet for kun gennemsnit.