it-swarm.com.de

Sammeln Sie die Ausführungszeit für SQL Server-Abfragen in Sekunden

Ich versuche, eine Möglichkeit zu finden, die Antwortzeiten für SQL Server-Abfragen in den letzten zwei Tagen zu erfassen. Gibt es einen Weg, dies zu erreichen? Ich weiß, dass es die Abfragestatistiken von DMVs gibt, aber ich scheine nicht das zu erreichen, was ich benötigt habe. Ich habe keinen Zugriff auf den Abfragespeicher und kann ihn daher im Moment auch nicht verwenden.

Ich suche nach einer Antwortzeit für Abfragen von SQL Server, da ich Leute habe, die den SQL Server beschuldigen, aber ich kann keinen Speicherdruck/CPU-Druck oder irgendwelche Engpässe sehen. Daher wurde jetzt versucht, die Antwortzeiten für Abfragen zu ermitteln, die auf dem Server ausgeführt wurden.

Vielen Dank

4
william345

Es gibt in der Tat mehrere Methoden.

Abfragespeicher

Kann ich Query Store empfehlen, da Sie SQL Server 2016 haben? Sie können es pro Datenbank über das Menü "Eigenschaften" in SSMS oder durch Ausführen eines ähnlichen Skripts wie folgt aktivieren:

USE [master]
GO
ALTER DATABASE [TestDB] SET QUERY_STORE = ON
GO
ALTER DATABASE [TestDB] SET QUERY_STORE (OPERATION_MODE = READ_WRITE, QUERY_CAPTURE_MODE = AUTO)
GO

Nach dem Einschalten können Sie Details zur Abfrageleistung anzeigen.

SSMS view:

Gotchas: Faire Warnung - Wenn Sie den Query Store aktivieren, wird der Plan-Cache geleert! Der Abfragespeicher als neuere Funktion kann einige Macken aufweisen. Ich habe mehrere mich selbst. Was die Leistung angeht, sehe ich, dass sie in Umgebungen mit 20.000 Batches/Sek. Und nur ein paar Prozent CPU-Overhead verwendet wird.

DMVs

Eine andere Möglichkeit ist die Verwendung der dmvs. Diejenige, die Sie in diesem Fall suchen, ist sys.dm_exec_query_stats, insbesondere die Spalten "elapsed_time". Hier ist eine Abfrage, um die letzten Abfragen mit langer Dauer anzuzeigen.

SELECT TOP 50
st.text,
SUBSTRING(st.text, (qs.statement_start_offset/2) + 1,  
    ((CASE statement_end_offset   
        WHEN -1 THEN DATALENGTH(st.text)  
        ELSE qs.statement_end_offset 
    END - qs.statement_start_offset)/2) + 1
) AS statement_text,
qp.query_plan,
qs.execution_count,
qs.last_execution_time,
qs.last_worker_time/1000000.0 AS last_worker_time_s, --this is CPU time
qs.last_elapsed_time/1000000.0 AS last_elapsed_time_s --this is clock time
FROM sys.dm_exec_query_stats qs  
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st 
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
WHERE last_execution_time > DATEADD(minute,-5,GETDATE()) --last 5 minutes
ORDER BY qs.last_elapsed_time DESC

Gotchas , die bei diesem dmv zu beachten sind, sind, dass es keine RECOMPILE Abfragen erfasst und keine abgebrochenen Abfragen erfasst ( Dies geschieht mit einem Abfragezeitlimit in der Anwendung.

SSMS

Wenn Sie die genaue Abfrage kennen, können Sie sie in SSMS ausführen und den tatsächlichen Ausführungsplan anzeigen. Markieren Sie die Auswahl und sehen Sie sich das Eigenschaftenfenster rechts an. Sie sehen äußerst hilfreiche Informationen zu CPU und Dauer (in Millisekunden). Ähnliche Informationen gibt es auch für die Betreiber.

Actual Plan

Zu den Fallstricken bei dieser Methode gehört die Tatsache, dass über SSMS übermittelte Abfragen nicht unbedingt das widerspiegeln, was mit Anwendungsabfragen geschieht. Kanonischer Link hier.

Kurz gesagt, ich empfehle Query Store.

6
Forrest

Zusätzlich zu den oben genannten tollen Tipps könnte ich vorschlagen, sich über leichtgewichtige erweiterte Ereignisse zu informieren.

Sie können einige der Lichtereignisse und Aktionen wie beschrieben überprüfen hier

Abhängig vom verfügbaren Speicher und der Anzahl der erfassten Ereignisse können Sie die erforderlichen Daten mit minimalen Auswirkungen auf die Leistung abrufen.

Am Ende müssen Sie testen und herausfinden, was für Ihren Server am besten und im Leistungsbereich liegt

1
KASQLDBA