DBAtlas · Atlas für Datenbankbetrieb

Die teuersten Abfragen im Plan Cache finden (CPU, Reads, Dauer)

SQL ServerPerformance

Befehl

SELECT TOP (20)
       qs.query_hash,
       SUM(qs.execution_count)                                       AS execs,
       SUM(qs.total_worker_time) / 1000                              AS total_cpu_ms,
       SUM(qs.total_worker_time) / SUM(qs.execution_count) / 1000    AS avg_cpu_ms,
       SUM(qs.total_elapsed_time) / SUM(qs.execution_count) / 1000   AS avg_ms,
       SUM(qs.total_logical_reads) / SUM(qs.execution_count)         AS avg_reads,
       SUM(qs.total_grant_kb) / SUM(qs.execution_count)              AS avg_grant_kb,
       COUNT(DISTINCT qs.query_plan_hash)                            AS plan_count,
       MAX(qs.last_execution_time)                                   AS last_exec,
       MIN(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 statement_text,
       MIN(DB_NAME(pa.dbid))                                         AS db
FROM   sys.dm_exec_query_stats qs
  CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
  OUTER APPLY (SELECT CONVERT(int, value) AS dbid FROM sys.dm_exec_plan_attributes(qs.plan_handle)
               WHERE attribute = N'dbid') pa
GROUP BY qs.query_hash
ORDER BY total_cpu_ms DESC;

-- To rank by reads: ORDER BY SUM(qs.total_logical_reads) DESC
-- Plan: SELECT query_plan FROM sys.dm_exec_query_plan(<plan_handle>);

Was es tut

Gruppiert Anweisungen im Plan Cache nach query_hash (Ad-hoc-Abfragen, die sich nur in Literalen unterscheiden, fallen in eine Zeile zusammen) und liefert Gesamt- und Durchschnittswerte für CPU, Dauer, logische Reads, Memory Grant und Planzahl.

Wann einsetzen

Wenn die CPU am Anschlag ist, bei der Beschwerde "der Server ist langsam", für Datenbanken ohne Query Store oder wenn du eine serverweite Sicht über alle Datenbanken brauchst.

Vorsicht

Sieht nur Pläne, die noch im Cache sind: Abfragen, deren Pläne durch Neustart, DBCC FREEPROCCACHE, Speicherdruck oder RECOMPILE verdrängt wurden, fehlen. Für dauerhafte Analyse mit Zeitfenstern Query Store verwenden. plan_count > 1 deutet auf Parameter-Sensitivität oder unterschiedliche SET-Optionen hin. Bei einem sehr großen Plan Cache kann die Abfrage einige Sekunden dauern; sicher.

In DBAtlas öffnen →

Verwandte Einträge