Soort van. Bekijk deze zoekopdracht:
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
Hiermee krijgt u de query's in de plancache in volgorde van hoeveel CPU ze hebben gebruikt. U kunt dit periodiek uitvoeren, zoals in een SQL Agent-taak, en de resultaten in een tabel invoegen om ervoor te zorgen dat de gegevens ook na opnieuw opstarten behouden blijven.
Wanneer u de resultaten leest, zult u zich waarschijnlijk realiseren waarom we die gegevens niet rechtstreeks kunnen correleren met een individuele database. Ten eerste kan een enkele query ook zijn echte database-ouder verbergen door trucs als deze uit te voeren:
USE msdb
DECLARE @StringToExecute VARCHAR(1000)
SET @StringToExecute = 'SELECT * FROM AdventureWorks.dbo.ErrorLog'
EXEC @StringToExecute
De query zou worden uitgevoerd in MSDB, maar zou de resultaten van AdventureWorks opvragen. Waar moeten we het CPU-verbruik toewijzen?
Het wordt erger als je:
- Samenvoegen tussen meerdere databases
- Voer een transactie uit in meerdere databases en de vergrendelingsinspanning omvat meerdere databases
- Voer SQL Agent-taken uit in MSDB die "werken" in MSDB, maar maak een back-up van afzonderlijke databases
Het gaat maar door. Daarom is het logisch om de prestaties af te stemmen op queryniveau in plaats van op databaseniveau.
In SQL Server 2008R2 introduceerde Microsoft functies voor prestatiebeheer en app-beheer waarmee we een enkele database kunnen verpakken in een distribueerbaar en implementeerbaar DAC-pakket, en het zijn veelbelovende functies die het gemakkelijker maken om de prestaties van individuele databases en hun toepassingen te beheren. Het doet echter nog steeds niet wat u zoekt.
Bekijk voor meer hiervan de T-SQL-repository op Toad World's SQL Server-wiki (voorheen op SQLServerPedia) .
Bijgewerkt op 29 1/2 om totale aantallen op te nemen in plaats van alleen gemiddelden.