Raczej. Sprawdź to zapytanie:
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
Dzięki temu uzyskasz zapytania w pamięci podręcznej planu w kolejności, w jakiej wykorzystali procesor. Możesz uruchamiać to okresowo, jak w przypadku zadania SQL Agent, i wstawiać wyniki do tabeli, aby upewnić się, że dane przetrwają po ponownym uruchomieniu.
Czytając wyniki, prawdopodobnie zdasz sobie sprawę, dlaczego nie możemy skorelować tych danych bezpośrednio z pojedynczą bazą danych. Po pierwsze, pojedyncze zapytanie może również ukryć swojego prawdziwego rodzica bazy danych, wykonując takie sztuczki:
USE msdb
DECLARE @StringToExecute VARCHAR(1000)
SET @StringToExecute = 'SELECT * FROM AdventureWorks.dbo.ErrorLog'
EXEC @StringToExecute
Zapytanie zostanie wykonane w MSDB, ale będzie sondować wyniki z AdventureWorks. Gdzie powinniśmy przypisać zużycie procesora?
Gorzej, gdy:
- Połącz między wieloma bazami danych
- Uruchom transakcję w wielu bazach danych, a wysiłek związany z blokowaniem obejmuje wiele baz danych
- Uruchom zadania agenta SQL w MSDB, które "działają" w MSDB, ale wykonaj kopie zapasowe poszczególnych baz danych
To trwa i trwa. Dlatego sensowne jest dostrajanie wydajności na poziomie zapytania, a nie na poziomie bazy danych.
W SQL Server 2008R2 firma Microsoft wprowadziła funkcje zarządzania wydajnością i zarządzania aplikacjami, które pozwolą nam spakować pojedynczą bazę danych w dystrybuowalny i wdrażalny pakiet DAC, a ponadto obiecują funkcje ułatwiające zarządzanie wydajnością poszczególnych baz danych i ich aplikacji. Jednak nadal nie robi tego, czego szukasz.
Więcej informacji znajdziesz w Repozytorium T-SQL na wiki Toad World's SQL Server (dawniej na SQLServerPedia) .
Zaktualizowano 29 stycznia, aby uwzględnić liczby całkowite, a nie tylko średnie.
