web-dev-qa-db-ja.com

SQL Serverクエリ実行時間を秒単位で収集する

過去2日間のSQLサーバークエリの応答時間を収集する方法を見つけようとしています。これを達成する方法はありますか？クエリ統計DMVがあることは知っていますが、必要なものを達成できていないようです。クエリストアにアクセスできないため、現時点ではそれを使用できません。

私はSQLサーバーを非難している人がいるので、SQLサーバーからのクエリ応答時間を探していますが、メモリの負荷/ CPUの負荷やボトルネックを確認できません。したがって、サーバーに対して実行されたクエリの応答時間を取得しようとしています。

ありがとう

sql-serversql-server-2016
4
william345

確かに複数の方法があります。

クエリストア

SQL Server 2016を使用しているので、クエリストアをお勧めしますか？ SSMSの[プロパティ]メニューから、または次のスクリプトのようなものを実行して、データベースごとに有効にすることができます。

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

オンにすると、クエリのパフォーマンスの詳細を確認できます。

SSMS view:

Gotchas：公正な警告-クエリストアをオンにすると、プランのキャッシュがクリアされます！クエリストアは、新しい機能として、いくつかの癖がある場合があります。私はいくつかに出くわしました myself。 パフォーマンスに関しては、20kバッチ/秒でCPUオーバーヘッドが数パーセントしかない環境で使用されていることがわかります。

DMV

別のオプションは、dmvsを使用することです。この場合に探しているのはsys.dm_exec_query_stats、特に「elapsed_time」列。以下は、最近の長時間のクエリを確認するためのクエリです。

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

このdmvで注意すべき点は、RECOMPILEクエリをキャプチャせず、キャンセルされたクエリをキャプチャしないことです（これは、アプリケーションからのクエリタイムアウトで発生します）。

SSMS

最後に、正確なクエリがわかっている場合は、SSMSで実行して実際の実行プランを確認できます。選択を強調表示し、右側のプロパティウィンドウを確認します。 CPUと期間（ミリ秒単位）に関する非常に役立つ情報が表示されます。オペレーターにも同様の情報が存在します。

Actual Plan

Gotchasこのメソッドを使用すると、SSMSを介して送信されたクエリが、アプリケーションクエリで発生したことを必ずしも反映しないという事実が含まれます。 ここに正規リンク

つまり、クエリストアを強くお勧めします。

6
Forrest

上記のすばらしいヒントに加えて、軽量の拡張イベントを確認することをお勧めします。

説明されているように、ライトイベントとアクションの一部を確認できます こちら

使用可能なストレージとキャプチャされるイベントの数に応じて、パフォーマンスへの影響を最小限に抑えながら必要なデータを取得できます。

最後に、サーバーのパフォーマンス範囲内で最適なものをテストして見つける必要があります。

1
KASQLDBA