Art von. Sehen Sie sich diese Abfrage an:
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
Dadurch erhalten Sie die Abfragen im Plan-Cache in der Reihenfolge, wie viel CPU sie verbraucht haben. Sie können dies wie in einem SQL Agent-Job regelmäßig ausführen und die Ergebnisse in eine Tabelle einfügen, um sicherzustellen, dass die Daten nach Neustarts bestehen bleiben.
Wenn Sie die Ergebnisse lesen, werden Sie wahrscheinlich erkennen, warum wir diese Daten nicht direkt mit einer individuellen Datenbank korrelieren können. Erstens kann eine einzelne Abfrage auch ihren wahren Datenbank-Elternteil verbergen, indem sie Tricks wie diese anwendet:
USE msdb
DECLARE @StringToExecute VARCHAR(1000)
SET @StringToExecute = 'SELECT * FROM AdventureWorks.dbo.ErrorLog'
EXEC @StringToExecute
Die Abfrage würde in MSDB ausgeführt, würde aber Ergebnisse von AdventureWorks abrufen. Wo sollen wir den CPU-Verbrauch zuordnen?
Es wird schlimmer, wenn Sie:
- Zwischen mehreren Datenbanken verbinden
- Führen Sie eine Transaktion in mehreren Datenbanken aus, und der Sperraufwand erstreckt sich über mehrere Datenbanken
- Führen Sie SQL Agent-Jobs in MSDB aus, die in MSDB "funktionieren", aber sichern Sie einzelne Datenbanken
Es geht weiter und weiter. Aus diesem Grund ist es sinnvoll, die Leistung auf Abfrageebene statt auf Datenbankebene zu optimieren.
In SQL Server 2008R2 hat Microsoft Leistungsverwaltungs- und Anwendungsverwaltungsfunktionen eingeführt, mit denen wir eine einzelne Datenbank in ein verteilbares und bereitstellbares DAC-Paket packen können, und sie sind vielversprechende Funktionen, um die Verwaltung der Leistung einzelner Datenbanken und ihrer Anwendungen zu vereinfachen. Es tut jedoch immer noch nicht das, wonach Sie suchen.
Weitere davon finden Sie in der T-SQL-Repository im SQL Server-Wiki von Toad World (früher bei SQLServerPedia) .
Aktualisiert am 29. 1., um Gesamtzahlen statt nur Durchschnittswerte einzuschließen.
